[cfe-dev] Allow constexpr in vector extensions

[John McCall via cfe-dev]

> On Aug 29, 2017, at 8:08 PM, Richard Smith via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> On 29 August 2017 at 16:51, Tom Westerhout via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> On 30/08/2017, Richard Smith <richard at metafoo.co.uk <mailto:richard at metafoo.co.uk>> wrote:
> > On 29 August 2017 at 05:45, Tom Westerhout via cfe-dev <
> > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> >
> >> [snip]
> >>
> >> It compiles cleanly with both GCC and Clang. However, if I try to make
> >> c constexpr, Clang tells me that operator+ on vectors is not
> >> constexpr. I'm wondering if there's a reason for that. There are no
> >> constrains from the Standard as these are intrinsics, so I see no
> >> reason why we couldn't allow constexpr code benefit from SIMD.
> >
> >
> > We could certainly allow this. However, last time this was discussed,
> > an objection was raised: materializing arbitrary vector constants is
> > not cheap on all targets, and in some cases user code is written in
> > such a way as to describe how a particular constant should be generated
> > (eg, start with one easy-to-lower constant, shift by N, add another
> > easy-to-lower constant). If we constant-fold arbitrary vector
> > operations, that sequence of operations will be lost in many cases,
> > requiring backend heroics to infer how to materialize the constant.
> >
> > I don't know to what extent the above is actually a valid objection,
> > though: in my testing, LLVM itself will fold together the operations
> > and in so doing lose the instructions on how to materialize the
> > constant. (And in some cases, Clang's IR generation code will do the
> > same, because it does IR-level constant folding as it goes.)
> 
> I guess it's a stupid question and I'm sorry for that, but I'm very new
> to all this, so could you maybe explain a bit what you mean by
> "materializing vector constants"? Does this just mean creating a vector
> constant in memory?
> 
> No, it means creating a vector constant in a vector register (ideally without loading it from somewhere in memory, since that tends to be slow and have a large code size).
> 
> If it does, then my first guess would be to use
> inline asm since we're talking about some specific target where user
> "knows better".
> 
> I generally agree that the user should have to explicitly express that they want their operation sequence to be preserved, either via inline asm or some other mechanism we provide them.
> 
> Anyway, could you maybe point me to an example to play around of user
> code specifying the materialisation process?
> 
> My observation was that such user code does not actually exist / work, because the vector operations get folded together at the IR level. That is: the objection to constant evaluation of vector operations in the frontend does not appear to be a valid objection (perhaps it once was, before the middle-end optimizers started optimizing vector operations, but not any more).

I agree, and I would only add that the original argument never seemed to justify (1) rejecting it in an constexpr context and (2) not doing constant-initialization of globals, especially static locals.  As inefficient as loading an arbitrary vector constant from memory might be, performing dynamic lazy initialization is surely worse.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170830/01025d1a/attachment.html>