In D115161#3173792, @arsenm wrote:

I think this needs some more changes down in codegen to pass them through

• rebase on D115161

LGTM, cheers. Nit: there's a typo in the description. I think it should be "further up"?

Aha I just found D87304 - maybe @jdoerfert @fhahn @anna @dantrushin would be interested in this patch.

In D114423#3173046, @simoll wrote:

What's our status with this patch?
I know we have been discussing among VP folks to get this approved by somebody who had worked on align before.

LGTM from what I can see. Thanks!

• rebase and add missing word

Oh my, sorry about that... LGTM

In D112531#3163628, @nikic wrote:

Just to make sure that we don't end up with another incomplete solution: Are there any architectures where alignment could depend on both element size and total size? Are there any where it could depend on element type, i.e. where a vector of i32 and a vector of f32 may have different alignment?

• Use existing Chain over Root. No test changes.

LGTM but there's one clang-format issue that should be addressed. Thanks, @craig.topper!

Choose better numbers to remove confusing use of 128

ping, thanks

In D114795#3161370, @jrtc27 wrote:

Presumably this only affects IR with wacky return types, because Clang inserts an explicit sret parameter in the IR it generates when the ABI needs it?

• add RV32 RUN line

@tlively I would appreciate your thoughts on the WebAssembly test changes

• adjust formatting

Thanks, Craig. From what I can see, taking the alive2 for ceil and modifying it to what you've got for floor also times out rather than finding a verification error. If it works for you locally I'm happy.

LGTM other than nits. Thanks for the fix!

LGTM. Craig's comment in D114246 has helped pinpoint the problem for me. I dunno if it's worth commenting that in the test file or not.

• rebase and use 'operand' over 'argument'

• rebase and address feedback

LGTM

LGTM. Anyone else?

Generally looks good to me, thanks @HsiangKai

LGTM, thanks

In D113798#3143309, @craig.topper wrote:

In D113798#3143299, @frasercrmck wrote:

Perhaps we should run this across a set of benchmarks we're interested in?

We've been using this internally on our SiFive 7 series and U8. Should we check the CPU?

Perhaps we should run this across a set of benchmarks we're interested in?

In D109809#3139769, @Orlando wrote:

Hi, the tests added in this commit seem to be failing on some buildbots. E.g. https://lab.llvm.org/buildbot/#/builders/109/builds/26584

In D109809#3139769, @Orlando wrote:

Hi, the tests added in this commit seem to be failing on some buildbots. E.g. https://lab.llvm.org/buildbot/#/builders/109/builds/26584

In D109809#3139396, @tangxingxin1008 wrote:

Hi @craig.topper @frasercrmck , I don’t have commit access, can you land this patch for me? Thanks.

LGTM too other than nits. Thanks, @craig.topper!

Sorry for not being very prompt on this one. I'll try and think about it in more detail later.

LGTM.

Though the clang-format thing should probably be addressed.

LGTM.

To what extent is this generic code that other targets would benefit from?

LGTM, good catch!

• rebase on top of D113022

ping

In D113325#3115732, @craig.topper wrote:

In D113325#3115003, @frasercrmck wrote:

Do we want to do the same for fixed-length vectors?

Fixed length vectors has a loop that sets every opcode to Expand.

Do we want to do the same for fixed-length vectors?

In D113209#3111194, @sdesmalen wrote:

In D113209#3111176, @frasercrmck wrote:

How does this interact with vscale_range? Could it perhaps automatically infer getVScaleForTuning using that? Or is the idea the target ultimately chooses?

The two are actually quite different; vscale_range specifies the range of vscale that the compiled binary is compatible with. LLVM guarantees that the compiled binary is correct for that vscale_range. VScaleForTuning can be set separately by mcpu/mtune and will purely tune the cost-model without changing the requirements on vscale. This means it doesn't change the compatibility of the binary, it just helps choose a better VF for the CPU it compiles for.

• rebase

How does this interact with vscale_range? Could it perhaps automatically infer getVScaleForTuning using that? Or is the idea the target ultimately chooses?

Makes sense, LGTM. Cheers.

ping

Thanks, Craig. Good point about opt. Is that official acceptance or would you like to wait for other comments?

• rebase on top of 'allones' tests pushed earlier

fix typos
add missing pointer mangling to examples

• rebase
• fix accidental unreachable due to bad rebasing

LGTM but either you need to land D110675 and rebase, or add D110675 as a parent revision. That way it's easier to see how this patch improves things.