<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></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="">Ok, I raised the priority back to Normal in the bug, since the work around wasn't good enough.</div></blockquote><div><br class=""></div>Sorry, looks like a false alarm; I was missing a set of brackets in my macro definitions for vld/vst and they weren’t rebuilt properly after being fixed. This does then generate correct code with both GCC and LLVM, and in LLVM all the redundant load/stores are correctly removed.</div><div><br class=""></div><div>I’ve still sufficiently scared myself about aliasing, and GCC still suffers from some additional temporaries, so I’m going to use a lazy-evaluation template approach instead. That will lose the natural support for chained multiply that the simple return by value offers but I have more confidence in the correctness of the approach than the workaround I previously suggested.</div><div><br class=""></div><div>Simon</div><div><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">Cheers, <br class="">
Renato </p>
<div class="gmail_quote">On 13 Jan 2015 11:57, "Simon Taylor" <<a href="mailto:simontaylor1@ntlworld.com" class="">simontaylor1@ntlworld.com</a>> wrote:<br type="attribution" class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
> On 5 Jan 2015, at 13:08, Renato Golin <<a href="mailto:renato.golin@linaro.org" class="">renato.golin@linaro.org</a>> wrote:<br class="">
><br class="">
> On 5 January 2015 at 12:13, James Molloy <<a href="mailto:james@jamesmolloy.co.uk" class="">james@jamesmolloy.co.uk</a>> wrote:<br class="">
>> For this reason Renato I don't think we should advise people to work around<br class="">
>> the API, as who knows what problems that will cause later.<br class="">
><br class="">
> I stand corrected (twice). But we changed the subject a bit, so things<br class="">
> got different midway through.<br class="">
><br class="">
> There were only two codes: full C, with pointers, vectorized some<br class="">
> times; and full NEON, with extra loads. The mix between the two came<br class="">
> later, as a quick fix. My comment to that, I agree, was misplaced, and<br class="">
> both you and Tim are correct is asking for it not to be used as a<br class="">
> final solution. But as an interim solution, with the care around<br class="">
> alignment, endian and all, it is "fine”.<br class="">
<br class="">
After a bit more testing applying the pointer dereferencing workaround in my real code (which has some layers of templates and inline functions) I’ve decided against using it in practice.<br class="">
<br class="">
GCC produced incorrect code unless -fno-strict-aliasing was specified. It’s probably entirely entitled to do that, so it just seems too flaky to recommend in any case.<br class="">
<br class="">
Simon<br class="">
<br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>