Could you please clean up the test a bit? It contains references to attribute groups that don't actually exist (#0, #1). One attribute you do want to add is nounwind, to avoid the clutter caused by the CFI directives. In manually written tests we also generally don't include some of those dso_local, local_unnamed_addr, etc. In general, it would be nice to make it look less like Clang's output and more like something that can be easily read and reasoned about.

Optimize address mappings.

In D99087#2668857, @frasercrmck wrote:

Yes, fair enough. I've updated the diff to use the preferred type alignment. We can always revert for whatever reason. I'll try and take a look through the diffs later.

In D99087#2668842, @frasercrmck wrote:

In D99087#2668840, @frasercrmck wrote:

Hmm good catch. Shame there's no DAG wrapper for that method; targets don't typically use it. I could look into it before merging, if you like?

Using the preferred type align does produce changes in 7 of our tests. Maybe we should leave it to a follow-up patch? We'd be best verifying that each is correct.

Once update_mir_test_checks.py is tweaked we can start using it for this test, but let's merge it as-is for now. Thanks!

Just a heads-up about a possible pitfall of this patch, though I'm not sure it actually affects SystemZ.

Fixing alignment before truly abandoning, in case it's useful for D97514.

BTW, it shouldn't affect correctness but the original CreateStackTemporary would use (as part of that method's implementation) getPrefTypeAlign instead of getEVTAlign. In principle that would allow better alignment choices, although at the moment it probably would never make any difference.

Abandoned in favor of D99087. Thanks @frasercrmck!

LGTM.

Address review feedback (thanks @MaskRay!).

Rebased.
Tested with the sanitizer-x86_64-linux-android and sanitizer-windows buildbots, so this time there shouldn't be buildbot failures when committing.

• Add VarArg handling.
• Adjust tests.

@sequencer What's the plan for this patch?

There are certainly fewer changes to existing tests, compared with

D99068. But if @luismarques is right in that there is excessive stack
alignment then this patch needs further work.

LGTM.

• Precommitted the original test, to better show the difference caused by of the patch.
• Updated the existing tests. They seem to more broadly show the issue I noted about the excessive alignment/overly conservative stack size.

In D99068#2641075, @frasercrmck wrote:

My fix was more direct: I went over ArgValue and all of the SDValue PartValue = OutVals[i + 1]; as in the loop later in this block, and summed up all of the required getStoreSizes of their VTs, and took the maximum required alignment of each. Then created a stack temporary of that summed size and max alignment. I wasn't sufficiently happy with it and since I didn't get much indication that this was an urgent fix I didn't put it up for discussion - sorry about that. I can share my patch with you if you're interested.

In D99068#2641053, @frasercrmck wrote:

Does this happen to fix D95025? It's certainly in a similar area as my (WIP) fix that I never got round to publishing.

Superseded by D77384 and D97490.
I can confirm that the mips* XFAIL now passes (since D77384 landed on Feb 26). If wasm contributors are still interested in reviewing this patch I can update it to include only the immediate.ll test update.

I just looked at this again and I don't have the full context in my mind right now but won't the test just exercise the BareMetal toolchain and not your changes?

In D97646#2632810, @vitalybuka wrote:

It's rather recommendation then requirement. Feel free to commit as is.

In D96956#2573300, @vitalybuka wrote:

That's bad, but I don't see a better easy way to fix that.
Maybe you create some separate sanitizer_common_test_runtime lib.

Address review feedback.

In D97646#2607526, @vitalybuka wrote:

LGTM, but better if someone with RISCV experience checks this too

In D95025#2522375, @jrtc27 wrote:

Hm, I guess ideally we'd have an option for update_mir_test_checks.py to emit the stack info. I'll see if I can do that later today.

Before relanding, I need to check/fix the SizeClassAllocator64PopulateFreeListOOM test for Android x86, as the respective buildbot failed in the first landing attempt.

Fix silly mistake in the last update.

This still doesn't report that the multilib configuration came from GCC when it succeeds, does it? I suppose that's not a deal-breaker, but it would be nice to have. Would it be difficult to implement?

LGTM. Thanks!

In D95916#2629534, @MaskRay wrote:

Could you recheck? (I am quite certain it fixes your case)

In D95916#2627640, @MaskRay wrote:

With -g or -fasynchronous-unwind-tables, .debug_frame/.eh_frame has a label below _start. Its address is _start + 2 and its name is empty.
Neither addr2line nor llvm-symbolizer skips such a symbol with empty name.

LGTM.

This broke debug info for RISC-V. Test case with broken symbolization:

LGTM. Thanks!

This makes sense to me but I'm not quite sure about the implications, especially when we consider compatibility. I think we need more eyes on this patch.

LGTM.

LGTM.

(Perhaps it would have been better to have split it into the NFC patch and the rest?)

LGTM. Nice clean-up!

This patch seems to be in pretty good shape now.

LGTM. Thanks!

Why not just error out if passed "generic"? The error message could indicate that "generic-rv<XLEN>" should be used instead.
In other words, it's not clear to me what we're getting with the remap, particularly since it still prints a warning...?

Overall LGTM.
I just don't understand what you mean with "1-byte NOPs" in the patchable prefix case. Regular NOPs are emitted. Please clarify the comment/patch as needed.

Address review feedback.

LGTM.

Seems correct.

In D97966#2604312, @vsk wrote:

It's great to see this. Will these tests get picked up by an existing RISCV bot?

In D91717#2594301, @edward-jones wrote:

Probably not. I wasn't sure whether the macros made it more readable.

Now that RV32 and RV64 have separate implementations, is there still a point in keeping the LOAD/STORE/STRIDE macros?

From some quick testing, it seemed that you could trim this test down a bit.
You're also adding # REQUIRES: asserts but not actually checking for any debug output.
Also, it would be nice to add a comment documenting the logic of this test, unless new CHECKs of the debug output make it more obvious.

LGTM.
Thanks @jrtc27 for the sexti32 review suggestions!

In D87997#2426709, @MaskRay wrote:

This does not look right to me. Newer architectures like aarch64/risc-v do not need to have .ctors/.dtors support. Can you investigate why -DCRT_HAS_INITFINI_ARRAY isn't set in your build instead?

Makes sense to me.

LGTM. Nice!