- User Since
- Mar 4 2015, 5:47 AM (377 w, 3 d)
Mon, May 9
Thu, May 5
Apr 21 2022
Apr 15 2022
Looks good. Thanks for documenting this !
Mar 22 2022
After looking at the full function and seeing how it is used: 'merge' is indeed the right operation to use here.
Unfortunately, the context of this patch is not available :(
Feb 3 2022
Hi @hkao13 You happen to have some reduced testcases that show the problem ? Thanks !
Jan 31 2022
LGTM. Thanks !
Sorry about not mentioning it with the previous part.
I checked the testcases for now and found some interesting effects. Can you comment on those ?
- the need to implement the 'based on' relationship, also in a a way that clang is producing code, where this dependency is not easily seen. The same restrict pointer usage can appear in different blocks at different places.
You need to elaborate this a bit more, otherwise I don't understand what you mean.
Jan 25 2022
It should be possible, but I am not sure it makes a lot of sense: Looking at the big picture, this proposed set of patches for providing ptr_provenance is a logical next step. My intention is that these patches only go in once all of them have been reviewed and accepted. At that time the basic infrastructure is available for the full restrict patches, which means that the next steps will start making use of this basic infrastructure.
The current users of the 'GetUnderlyingObject' can keep their behavior (for now), being: look for the underlying object following the computational path of the pointer. With more actual usage of the ptr_provenance, some of those GetUnderlyingObject users can switch to the provenance path, which should result in a speedup.
The more tricky changes are related to some of the bugs where the provenance of pointers gets switched and to N2676. Once the base infrastructure is there, we can also fix those.
Jan 24 2022
Jan 19 2022
Jan 4 2022
Dec 20 2021
ping2 @stephenneuendorffer : could you check and comment on P.TypeBitWidth vs P.IndexBitWidth on line 715 ?
Dec 14 2021
Dec 11 2021
We're almost there. But the testcase is now not testing what it should be testing. Also the unused CHECK: must be adapted.
Dec 10 2021
Dec 9 2021
When I try out the example on llvm-13, I get a 'omnipotent char' tbaa description. That should be ok in general. When I replace the 'float _Complex' with 'double', I do get the 'double' tbaa. That might be a better example for the testcase ?
Not sure how you can construct a test that triggers this problem, but in our out-of-tree version, this triggered problems.
Dec 7 2021
Do you have a testcase ?
Dec 2 2021
Dec 1 2021
A number of buildbots started failing after submission. Reverted for now so we can investigate if the new produced errors are valid or not.
Nov 18 2021
Nov 17 2021
Rebased to 8924ba3bf8c6b0e8d14dff455e4e449a426a2700 (November 17, 2021)
Nov 8 2021
Nov 5 2021
Oct 15 2021
Oct 14 2021
Actual fixed version.
Fixed test crash issue as suggested by @deadalnix
Oct 13 2021
I added a llvm-c echo test in D111751, together with the ptr_provenance support.
Updated after LLLexer change in D111160
Moved into D111159
Added missing LLLexer support.
Thanks for the feedback !
Oct 12 2021
Oct 11 2021
LangRef update. Refer to `unknown_provenance` now.
Refer to UnknownProvenance instead of ConstantPointerNull in comment of getUnderlyingObject.
Also test that parsing unknown_provenance works.
- Small cleanup of useless comment
- NOTE: The LangeRef change explaining the purpose of unknown_provenance is done in D104268
Oct 5 2021
- Note: still need to update the (obsolete) comment
- use llvm::hash_combine instead of xor for combining the different elements. This avoids hash clashes when ptr == ptr_provenance
- make use of UnknownProvenance