<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Tim,</div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">
Thanks for your example.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Well, take a look at the file I attached for example. Running "opt" on<br>

it allows inlining and the real alignment of 8 is propagated to the<br>
load. As a result, you'd get different results depending on<br>
optimisation level (if we used "ld1 {v0.4h}").<br>
<div class=""><br></div></blockquote><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">
I don't this is a good example to illustrate the bad consequence. For this case, we would always have correct result for little-endian, right?</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">
<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">And for big-endian, the semantic should be guaranteed by the programmer, so I would treat it as invalid code, and programmer intends to mixing/casting the alignment. If programmer wants to have a 'stable' result for both 'inline' and 'non-inline', she/he should not explicitly write alignment like this.</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">If this is generated by auto-vectorizer, I would expect the action of storing data into that var uses st1, then the 'var with alignment 8' would be transparent, I mean if only we always use ld1/st1 in pair, we would not have issue. If the code writing var is in a different module, and probably it's possible the action of writing var is str, but isn't it an interface programmer should have known about the layout and why she/he use 'alignment 2' on purpose?</div>
</div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">As Albrecht mentioned, maybe the solution is "<span style="font-family:arial,sans-serif;font-size:14.399999618530273px">The frontend must give the backend a totally different type for short vectors</span>". To some extension, I agree with his point.</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
> If we don't use ld1 for "align 2" case, which instruction we should<br>
> use? ldr requires total size alignment, otherwise exception would<br>
> be raised if strict alignment is enabled.<br>
<br>
</div>If we decided to support strict alignment mode efficiently, we would<br>
probably want to emit an "ld1 {v0.8b}" (i.e. always use the .8b or<br>
.16b version), since that's got the same semantics as ldr. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">It is only true for little-endian, isn't it?</div>
</div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">If we always use ldr/str for bit-endian without caring about alignment,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">
1) It would not work for non-strict mode, because the address might be unaligned.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">2) The data may come from a real array of elements rather than HVA, and the semantic of using ldr/str is conflict with the end-user's definition, because on memory address of an array, we always expect the element with lower index is located at lower address. it would bring issues crossing different modules built with different tools.</div>
</div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Thanks,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">-Jiangning</div>
</div></div>
</div></div>