Stream: t-compiler

Topic: simd-pass-by-value


nikomatsakis (Oct 16 2018 at 14:10, on Zulip):

@nagisa would you be up to review #55073? It's a PR by @Alex Crichton to ensure we pass SIMD arguments by value

nikomatsakis (Oct 16 2018 at 14:10, on Zulip):

Not sure who would be a good choice, it's basically a big blob of C++ code

rkruppe (Oct 16 2018 at 14:18, on Zulip):

I'd volunteer but I am not sure I'll have the time to do it in the next few days

nikomatsakis (Oct 16 2018 at 14:26, on Zulip):

I skimmed it but I don't really know much about LLVM IR

rkruppe (Oct 16 2018 at 14:28, on Zulip):

From skimming it seems like the exact sort of fiddly IR manipulation which I'm accustomed to, but that doesn't free me from having to read it very carefully, which takes time =/

nagisa (Oct 16 2018 at 14:36, on Zulip):

I did give it a pass.

nagisa (Oct 16 2018 at 14:36, on Zulip):

I’d rather an alternative approach :slight_smile:

nagisa (Oct 16 2018 at 14:51, on Zulip):

@rkruppe do you know if it is possible to have arbitrary attributes on functions/arguments/etc?

rkruppe (Oct 16 2018 at 14:51, on Zulip):

It is!

rkruppe (Oct 16 2018 at 14:51, on Zulip):

You can create an attribute out of an arbitrary string

nagisa (Oct 16 2018 at 14:53, on Zulip):

hmm… @Alex Crichton would you mind looking into whether the promotion strips those arbitrary "strings"?

nagisa (Oct 16 2018 at 14:54, on Zulip):

I’d be entrely fine with r+ing that PR if it didn’t also demote that "#[nomangle] extern" function

rkruppe (Oct 16 2018 at 14:55, on Zulip):

Promotion (and other passes that fiddle with the signature) should copy over function attributes. Many of them are important for semantics, and many others should be preserved because they are really important for optimizations.

nagisa (Oct 16 2018 at 14:55, on Zulip):

if LLVM does not end up stripping our custom attribute you then could selectively demote only the arguments with our attribute (i.e. we know for sure it is fine to demote those)

rkruppe (Oct 16 2018 at 14:57, on Zulip):

Oh do you mean a function attribute or a parameter attribute? The latter can't be blindly copied over so I'm less sure what arg promotion does to it

rkruppe (Oct 16 2018 at 14:57, on Zulip):

Since this is really about Rust ABI vs other ABIs, a function attribute should be sufficient

nagisa (Oct 16 2018 at 14:57, on Zulip):

Oh do you mean a function attribute or a parameter attribute? The latter can't be blindly copied over so I'm less sure what arg promotion does to it

I meant parameter one, but I think argument one would be just fine as well, I think

Alex Crichton (Oct 16 2018 at 14:57, on Zulip):

During argument promotion argument parameters are lost

Alex Crichton (Oct 16 2018 at 14:58, on Zulip):

I think though we can probably skip all non-internal functions in demotion

nagisa (Oct 16 2018 at 14:58, on Zulip):

at least I cannot immediately think of a case where for our use-case there would be any difference between two.

Alex Crichton (Oct 16 2018 at 14:58, on Zulip):

and that should skip the boundary and not affect the correctness at all

rkruppe (Oct 16 2018 at 14:58, on Zulip):

A lot of Rust-ABI functions are external, but I guess those wouldn't get their arguments promoted in the first place?

Alex Crichton (Oct 16 2018 at 14:59, on Zulip):

correct

nagisa (Oct 16 2018 at 14:59, on Zulip):

Right. I would be fine with skipping the external functions as well.

Alex Crichton (Oct 16 2018 at 14:59, on Zulip):

argument promotion only runs on internal functions

rkruppe (Oct 16 2018 at 15:00, on Zulip):

It's hypothetically possible that a function is internal when argument promotion runs and is made external afterwards. I don't think that would actually happen though.

rkruppe (Oct 16 2018 at 15:01, on Zulip):

One nice thing about the attribute route, though, is that we could also patch argument promotion to not promote functions with that attribute (would be a small patch)

nagisa (Oct 16 2018 at 15:02, on Zulip):

We should really avoid patching our own LLVM like that, though, because there are users with their own LLVM versions patched to various degrees.

nagisa (Oct 16 2018 at 15:02, on Zulip):

but yeah.

rkruppe (Oct 16 2018 at 15:03, on Zulip):

I wouldn't want to rely solely on that, even when building with our LLVM fork, since there might be other passes that do a similar transformation, but it would be almost-free defense-in-depth

Last update: Nov 22 2019 at 05:35UTC