<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 29, 2017, at 8:08 PM, Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On 29 August 2017 at 16:51, Tom Westerhout via cfe-dev<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><span class="gmail-">On 30/08/2017, Richard Smith <<a href="mailto:richard@metafoo.co.uk" class="">richard@metafoo.co.uk</a>> wrote:<br class="">> On 29 August 2017 at 05:45, Tom Westerhout via cfe-dev <<br class="">><span class="Apple-converted-space"> </span><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class="">><br class=""></span>>> [snip]<br class=""><span class="gmail-">>><br class="">>> It compiles cleanly with both GCC and Clang. However, if I try to make<br class="">>> c constexpr, Clang tells me that operator+ on vectors is not<br class="">>> constexpr. I'm wondering if there's a reason for that. There are no<br class="">>> constrains from the Standard as these are intrinsics, so I see no<br class="">>> reason why we couldn't allow constexpr code benefit from SIMD.<br class="">><br class="">><br class="">> We could certainly allow this. However, last time this was discussed,<br class="">> an objection was raised: materializing arbitrary vector constants is<br class="">> not cheap on all targets, and in some cases user code is written in<br class="">> such a way as to describe how a particular constant should be generated<br class="">> (eg, start with one easy-to-lower constant, shift by N, add another<br class="">> easy-to-lower constant). If we constant-fold arbitrary vector<br class="">> operations, that sequence of operations will be lost in many cases,<br class="">> requiring backend heroics to infer how to materialize the constant.<br class="">><br class="">> I don't know to what extent the above is actually a valid objection,<br class="">> though: in my testing, LLVM itself will fold together the operations<br class="">> and in so doing lose the instructions on how to materialize the<br class="">> constant. (And in some cases, Clang's IR generation code will do the<br class="">> same, because it does IR-level constant folding as it goes.)<br class=""><br class=""></span>I guess it's a stupid question and I'm sorry for that, but I'm very new<br class="">to all this, so could you maybe explain a bit what you mean by<br class="">"materializing vector constants"? Does this just mean creating a vector<br class="">constant in memory?</blockquote><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">If it does, then my first guess would be to use<br class="">inline asm since we're talking about some specific target where user<br class="">"knows better".<br class=""></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">Anyway, could you maybe point me to an example to play around of user<br class="">code specifying the materialisation process?</blockquote><div class=""><br class=""></div><div class="">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).</div></div></div></div></div></blockquote><div><br class=""></div>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.</div><div><br class=""></div><div>John.</div></body></html>