In D150851#4546075, @Mel-Chen wrote:

In D150851#4542688, @Joe wrote:

3. Only target induction variables that determine the branch condition in the loop latch. With this approach, we can indirectly determine whether the induction variable is signed using loop guards, and directly perform vectorization according to the signed overflow is undefined behavior.

@Mel-Chen I like this option. But I don't think I understand fully - what's the purposes of determining whether the induction variable is signed?

We need to determine whether we should use umax or smax in the middle.block. Currently, we have only implemented smax because the application of {1,+,step} unsigned induction variables is relatively uncommon.

3. Only target induction variables that determine the branch condition in the loop latch. With this approach, we can indirectly determine whether the induction variable is signed using loop guards, and directly perform vectorization according to the signed overflow is undefined behavior.

Add default ABI to multilib flags if none supplied

Theoretically, I think this matching of multilibs could be done without the need for multilib.yaml, but it is indeed much easier considering the logic is already there.

The mapping symbol seems to be getting stripped out at the linker stage (either ld or lld), but I'm not sure why. Will continue to look into it.

Thanks for explaining. I found that when I was writing a regex to match flags it was helpful to have a part of the string I could be sure would be there to avoid matching the wrong type of flag, and march= helped with that. I also worry that names from different types of flags could clash without some kind of namespacing.

The main trouble I had was at that point we don't have a reference to the ToolChain, so calling getMultiSelectionFlags was not possible. [...] I'm not sure what the solution here is.

I see two options:

1. Split getMultiSelectionFlags into needs-ToolChain and doesn't-need-ToolChain parts, with the former calling the latter. From Gnu.cpp, call the latter, with the limitation that it can use fewer flags.
2. Pass a ToolChain to the Gnu.cpp functions.

So again, I took these patches for a spin with RISC-V. As I mentioned before, I was using a GCC installation, so the multilib selection happens inside Gnu.cpp (findRISCVBareMetalMultilibs). The main trouble I had was at that point we don't have a reference to the ToolChain, so calling getMultiSelectionFlags was not possible. I had a go at making this function static, and it was mostly fine as you could just pass in the Triple and Driver, however getSanitizerArgs was not possible. I'm not sure what the solution here is.

FWIW I tried this patch out with RISC-V multilibs, and it works a treat. It solves the multilib reuse problem and relaxes the order of non-standard extensions. I did have to copy some of the logic from BareMetal.cpp to Gnu.cpp as was using a GCC installation.

Updated diff. Now a very small change.

Ping

Ping

In D120908#3358301, @labrinea wrote:

My understanding is that function specialization of such constant arguments is controlled by the option -function-specialization-for-literal-constant. That is disabled by default as it increases compilation times. I measured how it affects instruction count using perf when compiling the llvm test suite. It was generally neutral except for the benchmark SPASS which was regressed by 4%.

Add exhaustive correctness test.
Also remove signage test in binaryXor, as the common bits would be 0 anyway, thus creating a full set regardless.

Fix malformed diff.

LGTM, but probably wait for someone more experienced to upvote :)

What about G_OR and G_XOR? Is there a reason why they're not listed?

If you're supporting a pointer value return type, should there be a test for this?

Rebased on current head.

In D68328#1758323, @igorb wrote:

LGTM,
Thanks

Addressed @igorb 's comments.

Updated diff:

After further review and testing, I have found that changing the effective SCEV type to be the pointer index type does not work. Though neither does it work when assumed to be pointer size. In many places, these are assumed to be the same. I'm unsure of which way to go with this. Do I force effective SCEV type to be the pointer size and enforce this, or change it to be index size and enforce this?

Ping