Please use GitHub pull requests for new patches. Avoid migrating existing patches. Phabricator shutdown timeline
Jul 25 2023
The openmp runtime needs to do the same if not being done already.
Jul 24 2023
Change remark order and add static stack w/ indirect function call test case
Jul 23 2023
Update clang frontend test
Remove conditional and consolidate new test into existing remarks test
It is part of the kernel meta data that is passed to the runtime to indicate the compiler can't determine the required stack amount use of the kernel and to tell the runtime it needs to check the value set from hipDeviceSetLimit.
I don't see how this conveys any information. The compiler writes the stack size to be allocated. If it doesn't know what is sufficient, it's going to request some maximum and hope for the best.
The runtime allocates the requested size. If it has a bit saying "but use less if you know that's safe", then it can do nothing with that bit unless it has extra information. If it has that extra information, it doesn't need this bit.
Therefore instead of adding printing stuff related to this Boolean flag, we should delete the Boolean flag.
What's the use case I'm missing which makes this flag necessary/beneficial?
What is this bit used for? Codegen and debug info emission don't need it. I'm not sure what sets CurrentProgramInfo.DynamicCallStack at present either.
Jul 22 2023
Jul 18 2023
is the build line I was using. The unit that crashes is:
FWIW, the lit checks were failing for me with with GCC 8.3 so that GCC version check may need to be more inclusive.
Don't start this 😅
At this point, I'm very much out of my comfort zone.
I had to install custom PPA only to get gcc-7 and gcc-8 on my system, as those are no longer available officially.
I managed to get 7.5.0 and 8.4.0, so I could fix this. However, to get 8.3, I'd assume I need to compile gcc only for this.
And I'm not sure if we should expect all minor versions of a compiler. To me, it makes more sense to support only the latest revision of a major compiler version.
I intentionally, waited for the Harbormaster to see breakages. Also, after I landed the patch, I waited a couple of days until I pushed some other changes to build on top of this feature to make sure we didn't need to revert many changes if something breaks.
IMO if we would really care about these compilers, we should have them in BuildKite.
Jul 17 2023
Jul 4 2023
Jun 23 2023
skipping some of register scavenging if we already have a reserved register
remove unnecessary set functions
invert to reserve register by default and then have pass remove the register if unneeded
Jun 22 2023
variable, pointer/reference clean up
remove specific instruction offsets from distance calc
Swap out reserve register routine for TRI helper function
Update reserveReg calls in SIFrameLowering
Jun 21 2023
address review comments, add additional debug instruction test
Jun 20 2023
Jun 19 2023
clean up unused header files and an unused function
Reduce complexity of branch distance calculation substantially - we now just approximate branch size by assuming 8 bytes per instruction. Also updated pass name to be more representative of what the pass does.
Jun 16 2023
Any further comments on this? @arsenm Do you think we need to update the distance calculation or are OK to leave as is?
Jun 9 2023
add test for when maxed out on SGPRs
Jun 2 2023
Jun 1 2023
fix a type mismatch
update types in GCNPreRABranchDistance pass
update to bypass register scavenger if we've previous reserved ones
fix some tests
May 31 2023
rebase and address review comments
May 23 2023
addressing review comments.
May 19 2023
rebase and address some review comments
May 9 2023
Absolutely do not globally reserve s[6:7] for such things. Low SGPRs are very often given special meaning in function signatures.
Furthermore, is a global reservation even necessary? You could identify candidate long branches and give them a fake clobbered operand, so that the register allocator can just pre-choose a register pair, but not block it everywhere.
May 8 2023
address review comment
May 4 2023
address some review comments