Thanks for refactoring it! I think it's fully NFC.

In D125787#3528016, @frasercrmck wrote:

In D125787#3527694, @StephenFan wrote:

And I also worried that if the size of RVV padding is big enough, the size of the local scalar variable field is out of the range of 12 bits signed number. If it is necessary to add an extra scavenger spill slot for it?

We already reserve a scavenger slot if there are any RVV objects at all in the frame - I believe that this one reg is sufficient to cover this eventuality. I don't think there's anything special about RVV padding compared with just the number of scalar local variables being too large for a 12-bit int in the "regular" case.

LGTM.

And I also worried that if the size of RVV padding is big enough, the size of the local scalar variable field is out of the range of 12 bits signed number. If it is necessary to add an extra scavenger spill slot for it?

1. Replace std::string to StringRef
2. Remove size value for SmallVector

Thanks for confirming it! @kito-cheng

Use update_mir_test_checks.py to autogenerate check lines

In D123679#3461601, @luismarques wrote:

The fix looks fine.

Can you please clean up the Clang cruft from the MIR test file? And give it a meaningful name?
Shouldn't we also check the result of the pass?

If it helps, here's an automatically reduced test file, for reference:

|
  %struct.a = type { i32 }
  define i32 @b(%struct.a* %c) {
    %ab2 = getelementptr inbounds %struct.a, %struct.a* %c, i64 0, i32 0
    %1 = load i32, i32* %ab2, !tbaa !1
    br label %e.epilog
  e.epilog:
    %a.0.g = phi i32 [ 1, %e.epilog]
    br label %cleanup
  cleanup:
    %f.0 = phi i32 [ %a.0.g, %e.epilog ]
    ret i32 %f.0}
  !1 = !{}

1. rename test file to pr53662.mir
2. reduce pr53662.mir test file

Thanks for fixing it! @rogfer01

In D122490#3461606, @luismarques wrote:

I think this patch can be abandoned now?
Thanks for providing D123515 as an alternative.

ChangeLog:

1. Rewrite .ll test as MIR test
2. Add '-run-pass=prologepilog' argument to test RUN line
3. Add a CHECK line.

ping

Thanks @MaskRay, @asb !

In D122490#3419774, @kito-cheng wrote:

@StephenFan do you or other PLCT folks could help on implement that for LLVM?

I will implement this for LLVM.

This patch makes sense to me and I think it is a correct fix.
In LLVM MC, the STI's feature bits is not mutable, it was determined by the command line before parsing the file. And to deal with directives like .option rvc, the Parser maintains an STI and replaces it with a new STI when the subtarget extensions were enabled or disabled. So we need to use MCAlignFragment's STI which is generated using the replaced STI by the parser. Is my understanding correct?

Address @MaskRay 's comments.

1. explicit default-argument to avoid error-prone
2. change riscv64 test to test the case when -mno-relax -mrelax specified.

Address @MaskRay 's comments

In D122490#3410911, @luismarques wrote:

What about the attributes? I thought that the attributes were basically a more flexible and extensible version of the Flags. But with this behavior we get RVC in Flags but not in Tag_RISCV_arch. That seems a bit confusing and maybe error-prone, although it does also match the GNU behavior.

Yeah, the attributes were missing in this patch. I will update it.

I'm not even sure in what cases this matters. Flags is documented as being "used by the linker to disallow linking ELF files with incompatible ABIs together" but C and non-C are always compatible with each other, assuming the target does support C.

RISC-V psabi says "When linking objects which specify EF_RISCV_RVC, the linker is permitted to use RVC instructions such as C.JAL in the relaxation process".

To be clear, if no one else has any opinion about this I think I'd still be in favor of merging this, as we would match the GNU tools and I don't see much downside, but this seems like a weird and non-ideal corner case, whichever way we slice it.

I am still confused about when do we need the RVC flag ? For example, if we have both .option rvc and option norvc in an assembly file, should RVC flag be emitted ? Or if we use command line -mattr=+c to assemble file, but option norvc is specified in assembly file, should RVC flag be emitted ?

@jrtc27, @kito-cheng Do you have any other comments ? :)

Grammatical fix

rebase and fix warning

Looks like a test is missing?

Ping. :)

Ping :)

Address @khchen 's comments.

Ping.

ping.

LGTM

Address @kito-cheng 's comments

fix

remove the content in patch D121073

undo

[RISCV] Generate correct ELF EFlags when .ll file has target-abi attribute

add test file

Address @jrtc27 's comments

fix typo

Address @fourdim 's comments

mask off the upper 2 bits of the value at the address and truncate the Value

clang-format and rebase