<div dir="ltr">I've attached a patch that should address both of your concerns. It adds the command-line option, and the defaults stays the same except for ARMv7+ Linux and PNaCl. I also moved the alignment test away from fast-isel.ll into its own file, and added invocations for each of these use cases. That allowed me to also rename some of the test functions to be more descriptive.<div>
<br></div><div>Please take a look and let me know if this new change does what you would expect.<br><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra" style>Comments below are separate from the review...</div>
<div class="gmail_extra"><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"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div class="im"><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><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?<br>
</div></div></div></blockquote><div><br></div></div><div>Most of the time, yes. However, we're talking about ARM, here...</div></div></div></div></blockquote><div><br></div><div style>I think I understand something: ARM is growing out of its typically embedded roots, and I currently care about LLVM's ARM as "consumer ARMv7a", whereas you want to also please other users who have typically been closer to the system. Would it be worth making a distinction between A/R/M profiles at some later time, or something along those lines?</div>
<div> </div><div><br></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 dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div class="im"><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><div>"Apple is vertically integrated and knows that it wouldn't ship a silly v6 CPU".<br>
</div></div></div></blockquote><div><br></div></div><div>This is not an Apple vs. the world issue, be sure of that. LLVM has more Darwin tweaks than any other just because Apple has historically spent the bulk of time&money on LLVM, more than any other company or group. Things are changing recently, but Apple still has a big share of the changes even today. Hardly surprising.</div>
</div></div></div></blockquote><div><br></div><div style>I'm sorry my comment was misleading. What I mean is: Apple has a great advantage here, and using that knowledge to get the best performance is the right thing to do. What I'm trying to do at the moment is to see what can be reused for other targets (I don't want to just fix PNaCl). I don't see this as adversarial at all, quite the opposite I greatly appreciate the work that's been put in!</div>
<div style><br></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 dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div>The problem here is that ARM is not x86. All modern x86 hardware (90's+) have a BIOS to correctly set-up the best options (have you ever seen BIOS code? It's horrendous), something that is not true for ARM. OSs like Darwin and Linux have total control on how to bring the hardware up, and this is orthogonal to what the hardware is capable or not.</div>
</div></div></div></blockquote><div><br></div><div style>Shouldn't this just be:</div><div style><div>  mrc p15, 0, r0, c1, c0, 0</div><div style>  orr r0, r0, #2</div><div>  mcr p15, 0, r0, c1, c0, 0</div><div>?</div>
<div><br></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 dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">
<div>What Anton was referring to, and I agree, is that *that* kind of code *will* break with the current change. Adding a new default that traps on current user code *IS* a regression. What we were saying is that, for the sake of future folks getting more juice out of LLVM, we'll break much of the existing bare metal code base, which is not acceptable.<br>
</div></div></div></div></blockquote><div><br></div><div style>Agreed that as-is my previous change should, at the minimum, have been prominently in release notes, and most probably at some major milestone. I hope the attached change is more agreeable.</div>
<div style><br></div></div></div></div></div>