LGTM too.

I'm not suggesting moving it into the same model, but the backend should figure out the user SGPR count given the formal argument list in the IR

LGTM if clang-format thing is fixed.

In D114273#3144825, @t-tye wrote:

@tpr does this change break anything in LLPC?

Previous commit being fixed up: rG1128311a19179ceca799ff0fbc4dd206ab56e560
I will also added that to the commit message.

V2: Extract AMDGPU-add-symbolizer code and my new logic into a separate
function. Only enable new functionality with SymbolizeOperands to bring
it into line with X86 (and stop existing tests failing).

In D93125#2657913, @foad wrote:

Please make the commit message a bit more descriptive than just "update".

Abandoning as it is the wrong fix.

In D96433#2554813, @smeenai wrote:

The NATIVE build is also used for cross-compilation scenarios (e.g. you're building on Windows but targeting Linux, but you still need tools like tablegen to be built targeting Windows), and for those cases, using the same CMAKE_TOOLCHAIN_FILE as the main build is completely incorrect.

What I've done to handle situations like this is set the CROSS_TOOLCHAIN_FLAGS_NATIVE cache variable to include the desired toolchain file for the NATIVE build (and any other desired CMake settings as well). Does that work for you? Something like -DCROSS_TOOLCHAIN_FLAGS_NATIVE="-DCMAKE_TOOLCHAIN_FILE=/path/to/your/toolchain/file" should do the trick.

This fix is wrong. I have a test build that went into an infinitely recursive loop of doing NATIVE builds.

V3: Add missing bits.

V2: Update ELFObjectFile.cpp and elf-header-flags-mach.yaml.

V3: Listed products. Marked as "xnack enabled".

V2: Fixed copy-o in AMDGPUUsage.rst change.

Abandoning after AMD-internal discussion. We're keeping the elf numbers I originally landed.

LGTM

V3: AMDGCNGPUs table in TargetParser.cpp needs to be in GPUKind order,

so fix the GPUKind order.

V2: Add clang changes. Put TargetParser list in order.

+Chris Bieneman

I am abandoning this, because it turns out that it is difficult to reliably detect whether we have a PAL pipeline or a PAL shader compilation. Instead, the LLPC linker will remove the padding, and then adds it back on after concatenating .text sections.

Ping.

V2: Review comments: Separate predicate function; early exit on CS.

V5: API change so client can choose whether array merging does merge or append.

V4: Added MapDocNode::erase methods.

V2: Fixed tests.

V3: Added assignment for const char *, otherwise it defaults to using

the bool one rather than the StringRef one.

V2: Added tests

With the nil/empty change, there is a change in behavior in that doing a map lookup "map[key]" with a key not previously in the map creates a new map entry that is empty rather than nil. That is more correct, but I have just discovered some code in LLPC relying on the old behavior. I can fix the LLPC code, but is the change in behavior going to cause any HSA problems?

Ping

In D79671#2030708, @scott.linder wrote:

Dinesh is working on merging metadata in ROCm CompilerSupport using MsgPackDocument, and it fell out that merging YAML metadata was also handled transparently. What is the advantage to doing this via a function pointer passed to readFromBlob? It doesn't seem to save any copies as you still need to be able to compare the nodes; is it just a matter of readability? Would it be reasonable to also add a callback for fromYAML?

V3: Removed unneeded nullptr arg.

Ping.

V2: Pass map key to merger function.

V2: Also fixed GS regs. Added test.

I don't know of any reason why it has to be fp. Maybe related to the prehistoric thing where isel used to need something to be fp to put it in a vgpr?

This got landed in a slightly different form because of conflicts with other sdiv64 etc tests.

V2: Also added gfx1010 to memtime test.