<div dir="ltr"><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 dir="ltr"><div class="im"><div class="gmail_extra">
<div class="gmail_quote"><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><span style="color:rgb(34,34,34)">Even more, the change in question actually is a regression for such</span><br>
</div>subtargets. Previously the code generated never trapped and the<br>present one traps. And starting to ask for additional cmdline flag is<br>a bad thing here IMO.<br></blockquote><div></div></div><br></div></div><div class="gmail_extra">
I have to agree with Anton, here. The results of unaligned access is a trap and code will fail, independent of the default on power on, boot code will set whatever they want and code bare metal code expecting aligned access will trap.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Let's be conservative in general and make Linux more performing.</div></div></blockquote><div><br></div><div><div>I disagree, but my opinion may not align with what's "LLVM-like": I think the default should be the saner and better-performing option, and that people writing operating systems, bootloaders and such should have a harder time (and I've mostly been in the later camp, I know the pain). The current state of LLVM ARM as I see it is that much has been tuned for Darwin/iOS, but is turned off out of paranoia for other platforms. This makes it pretty hard for other platforms (like PNaCl) to actually enjoy LLVM's power. Unaligned accesses is just one example of this, and I'm trying to fix the state of things in general, instead of just checking that it works for PNaCl and calling it a day.</div>
<div><br></div><div>As an example PNaCl doesn't do much that's special (as compared to an OS), and neither does Linux user-mode, but ARM FastISel plain doesn't work for them even though there's not actually much preventing me from turning it on.</div>
<div><br></div><div>So my rationale is: user-mode code should get the best out of LLVM, and system code should have a harder time. Is that the right approach for LLVM?</div><div><br></div></div><div><br><div class="gmail_quote">
<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">1. Define subtarget feature. Let's call it "allow unaligned access".<br>
Make it false by default<br>2. Enable it for Darwin and Linux / PNaCl + v7<br>3. Check for feature, not for subtarget here<br></blockquote><div><br></div><div style>Similar to what x86 does for fast unaligned support? Even there x86 does it per-hardware target, it's OS-independent. I'd argue that the code I submitted was checking for features (v6 and v7), the Darwin check is more of a "Apple is vertically integrated and knows that it wouldn't ship a silly v6 CPU".</div>
</div></div></div>