I'm sorry I can't be more decisive here since I wasn't deeply involved with the devirtualization work early on and so lack a lot of context. The general direction here seems fine to me -- given that we use metadata to express a large range of things, it seems ok to have metadata specific MD dropping policies. However, given that Hal originally objected to this, we should make sure he is on board.
I understand the motivation, thanks. The problem here is that, while we might want to avoid hoisting so that we don't strip the metadata, that only is better if we happen to inline into a function that then provides a concrete type. Otherwise, we should have hoisted. How about this: Add a parameter to LICM to control this choice: We can choose not to hoist during the early runs on LICM (which happen during inlining), and then hoist later (during the LICM invocation that runs after loop unrolling).
Nov 27 2018
Sep 11 2018
LGTM, but please wait for Javed to review
Sep 7 2018
Aug 14 2018
Can we spec !invariant.group in a way that lets us always keep the metadata when hoisting? Right now it isn't clear what happens if its contract is violated, i.e. what the behavior of this program is:store i32 0, i32* %ptr, !invariant.group !0 %x = load i32, i32* %ptr, !invariant.group !0 store i32 1, i32* %ptr, !invariant.group !0 %y = load i32, i32* %ptr, !invariant.group !0
though it seems like you're assuming the *load* has UB? Can we instead say that the second store has UB? That way we should be able to hoist the load instruction without dropping the metadata.
Aug 13 2018
Jul 19 2018
Jul 16 2018
Jul 12 2018
Jul 10 2018
Jul 3 2018
Jul 2 2018
Jul 1 2018
fixed addrspace cast
Jun 16 2018
Jun 15 2018
Jun 13 2018
- Fixed comments
@hfinkel is my response resonable?
Jun 11 2018
- Fixed templates
Jun 2 2018
s/loop unrolling/loop peeling/
I will had to take a look at this at some time, but from what I've heard the state of loop peeling in LLVM is not very sofisticated, and implementing the logic that I propose might be a little hard.
You say that you don't yet know if this is profitable yet. Do you have reason to believe that it might not be profitable (e.g., some example where it seems like we might want to constrain the behavior)? We almost never favor keeping metadata over doing other transformations, so I think it's worth being explicit about our reasoning here. Just saying "I don't know yet" is probably not sufficient, as we could say that about nearly all metadata, and in that case, change the default logic.
May 29 2018
And two facts..
- LLVM already replaces bzero with memset
- There are many source codes related to networking which uses bcopy, bcmp.
So I dont think this patch is totally useless.
Maybe @Prazek can do review of this patch for me?
May 28 2018
May 27 2018
Fixed missing vtable commponents
one more test
Added launder when going from possiblyNotDynamic to possiblyDynamic emitting strip for pointer -> int only if poitner is possiblyDynamic
Can someone with experience in Loop passes take a look at this?
May 25 2018
OK, so it seems that at least the tests in the second patch passes without this patch, so I am fine with committing it without this one for one (also Philip if you could take a look at that patch I would be grateful)
I am worried about cases, where the first instruction does not throw, but it we can't hoist it (e.g. it depends on the loop phi) and after that, there is an instruction that can be hoisted.
May 23 2018
Slitted commit into defining and using intrinsic
I thought we already had places in Sema that marked inline virtual methods as used, instantiated templates, etc. for devirtualization purposes when optimization was enabled. Did we rip that out?
I only recall the emitting available_externally vtables opportunistically, that is emitting it only if all the inline virtual functions are present (and they are not hidden).
May 22 2018
- Add more comments
@rjmccall do you have any thoughts on the best way to solve it?
May 19 2018
- small refactor
introduced mayBeDynamicClass and added more tests
Fixed flag passing
remove empty line
Add release note
- small fixes in tests
- Add deleted tests
- use getArgumentAliasingToReturnedPointer as it does not change behavior
- Fixed nit
May 18 2018
Refactored code to getArgumentAliasingToReturnedPointer and added few comments.
Please check out isKnownNonZero, as I think it could also use getArgumentAliasingToReturnedPointer.
What I want to know is: how did you decide what had to be modified? Did you just look for every place that handles returned arguments? If you had to describe to someone how to find the places that need modification, how would you do it? (because that's what we need in the comment).
Yes, I pretty much checked every place that uses CaptureTracking and looked for special handling of calls or uses of getUnerlyingObject.