The openmp runtime needs to do the same if not being done already.

Change remark order and add static stack w/ indirect function call test case

Update clang frontend test

Remove conditional and consolidate new test into existing remarks test

In D156040#4526036, @JonChesterfield wrote:

In D156040#4525771, @crobeck wrote:

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?

In D156040#4525769, @JonChesterfield wrote:

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.

is the build line I was using. The unit that crashes is:

In D155441#4509069, @steakhal wrote:

In D155441#4508400, @crobeck wrote:

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.

In D155441#4507897, @steakhal wrote:

In D155441#4507877, @MaskRay wrote:

Allegedly, GCC-8 and above builds just fine.

It would be nice to test this:)

I'll check that tomorrow.

rG853b2a84cb9902725752e9603011041ebe33c7bf

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

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

address review comments, add additional debug instruction test

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.

Any further comments on this? @arsenm Do you think we need to update the distance calculation or are OK to leave as is?

add test for when maxed out on SGPRs

fix a type mismatch

update types in GCNPreRABranchDistance pass

formatting

update to bypass register scavenger if we've previous reserved ones

fix some tests

formatting

rebase and address review comments

In D149775#4338257, @vpykhtin wrote:

What if we always reserve a register for long jumps?

addressing review comments.

rebase and address some review comments

In D149775#4327638, @nhaehnle wrote:

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.

address review comment

address some review comments