- User Since
- Oct 19 2020, 10:52 AM (18 w, 4 d)
Wed, Feb 24
Thank you very much for pointing that out @leonardchan !
I added this pass into both pass managers now.
Thanks for pushing this forward! I think this will be a nice transformation once all the details are worked out.
Thank you very much for all of your wonderful constructive feedback!
I learned much more about LLVM and IR internals.
Appreciate all your help!
- Rename the pass to RelLookupTableConverter to be consistent
- Addressed reviewers' feedback
- Added tests for user-defined lookup tables and hidden visibility
Wed, Feb 17
Tue, Feb 16
@lebedev.ri based on your feedback, I added it as a separate pass and added support for user-defined lookup tables.
Please let me know if you have any comments.
Implement it as a separate pass and apply it to user-defined lookup tables as well.
Fri, Jan 29
@mcgrathr gave some explanation to that:
Many backends generate PIC-friendly jump tables. This is about generating IR initializers that translate to the same kind of backend assembly expressions as those backends use for their jump tables.
Thu, Jan 28
- Simplified test cases and increased readibility of the tables
- Added x86_64 and aarch64 check and tiny or small code modes check to ensure 32 offsets
- Modified single value test case
Jan 21 2021
- Apply relative lookup table generation in fPIC mode
- Add a test case for single value case
- Remove hard-coding 64 bit pointers
- Improve implementation and test coverage
Jan 14 2021
- Add dso_local check
- Remove -relative-switch-lookup-table flag, and enable it by default
- Use shift instead of mul
- Remove /ARM test and merge it with /X86 test
Jan 13 2021
if (IsRelative) GenRelative else GenAbsolute
looks pretty ad-hoc, as-if some abstraction is missing.
Use llvm.load.relative intrinsic to compute the target address based on Leo's feedback.
Add a new Kind enumerator called RelOffsetArrayKind for relative lookup tables
Jan 12 2021
Thanks for the feedback!
Jan 11 2021
This optimization is only applied if the values have pointer types like strings to generate PIC friendly code for such cases.
If the values are not pointers but like integers, PIC friendly code is already generated without this optimization.
Addressed Leonard Chan's comments
Jan 8 2021
Dec 16 2020
I fixed it in
But that was just to make my test pass.
Ok, thank you!
I did not realize that typo after the merge, and sorry about that!
I fixed the typo that I introduced in https://reviews.llvm.org/D93420.
The problem in llvm/test/Bitcode/attributes.ll is clear?
@xur Instead of define void @f70() nocallback, it should be define void @f69() nocallback, right?
Dec 14 2020
This is missing a lang ref entry for nocallback and the attributes.ll test is arguably broken (see below).
Could you please elaborate on missing lang ref entry? Where that should be added?
Dec 8 2020
Add a new line at the end of the test file
Added more Sema test cases
Dec 7 2020
Only support leaf attribute in functions
Dec 3 2020
Nov 18 2020
Nov 11 2020
Nov 10 2020
Nov 9 2020
Nov 5 2020
Remove direct from description and ObjCMethod for Obj functionality
Nov 4 2020
Leaf attribute is specifically intended for library functions and I think all the existing usage of leaf attribute is in the library function declarations.
For ex, it is only used in syscalls in Fuchsia.
Therefore, I'm not sure whether it is really necessary to ban leaf attribute in function definitions.
Even though function attributes are typically intended to be used in the function declaration, compilers do not have policy to forbid using them in the function definition.
Nov 3 2020
Add a target into the test case
Nov 2 2020
Update the attribute documentation
Addressed the comments about the documentation
Oct 29 2020
Fix the typo in the test case
Add IR and bitcode tests