Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SROA: don't use unswitchtupleunion and explicitly use type name only #50522

Merged
merged 1 commit into from
Jul 13, 2023

Conversation

aviatesk
Copy link
Member

Since construction of UnionAll of Unions can be expensive. The SROA pass just needs to look at type name information and do not need to propagate full type objects.

if !((field_ordering === :unspecified) ||
(field_ordering isa Const && field_ordering.val === :not_atomic))
continue
end

# analyze this mutable struct here for the later pass
if ismutabletype(struct_typ_unwrapped)
if struct_typ_name.flags & 0x2 == 0x2 # if this struct is mutable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ismutabletype(struct_typ_unwrapped.wrapper)

The flags field is very unstable, so it is a bad idea to hard code assumptions about it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

struct_typ_name.wrapper is UnionAll so it is not applicable to ismutabletype. We probably want to define ismutabletypename?

Copy link
Member

@vtjnash vtjnash left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems much better. The argument_datatype function should probably be deprecated some day, but it is a very useful helper function when you don't want to go through the work of handling the Union generally.

Since construction of `UnionAll` of `Union`s can be expensive. The SROA pass just needs to
look at type name information and do not need to propagate full type objects.

- xref: <#50511 (comment)>
- closes #50511
@aviatesk aviatesk force-pushed the avi/follow-up-50502 branch from 279cbef to 14069ff Compare July 13, 2023 05:18
@aviatesk
Copy link
Member Author

@nanosoldier runbenchmarks("inference", vs=":master")

@nanosoldier
Copy link
Collaborator

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

@aviatesk aviatesk merged commit 9b73611 into master Jul 13, 2023
@aviatesk aviatesk deleted the avi/follow-up-50502 branch July 13, 2023 07:50
Keno added a commit that referenced this pull request Jul 14, 2023
Fixes the issue noted in [1] (#50522) and
adds a test to make sure that it doesn't regress.

[1] 9b73611#r121641452
aviatesk pushed a commit that referenced this pull request Jul 15, 2023
Fixes the issue noted in [1] (#50522) and
adds a test to make sure that it doesn't regress.

[1] 9b73611#r121641452
github-merge-queue bot pushed a commit that referenced this pull request Jul 15, 2023
Fixes the issue noted in [1] (#50522) and
adds a test to make sure that it doesn't regress.

[1]
9b73611#r121641452
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants