<div dir="ltr"><div><div>So, it seems there are enough people on the plus side, I just wanted to make sure we evaluate all sides before taking a decision to add syntactic sugar to LLVM assembler.</div></div><div><br></div>
<div>My main concern is still the same as earlier this year: the integrated assembler for ARM is still not complete, and the more extensions we add to the back-end, the harder it'll be to get it into production quality.</div>
<div><br></div><div>That said...</div><div><br></div><div><br></div>On 27 October 2013 01:02, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br>
<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 style="word-wrap:break-word">
<div><div class="im"><div><span style="color:rgb(34,34,34)">I agree.  These pseudo instructions seem like pure syntactic sugar that should never be produced by the disassembler.  That doesn't make them bad, in fact it makes them simpler to implement and reason about.</span></div>
</div></div></div></blockquote><div><br></div><div><br></div><div>I agree with this line of thought, though it's not necessarily simple to implement this specific one, because of the constant pools. You have to pay attention if there aren't many pools next to each other, or where is the best placement (due to proximity, relocations, alignment), etc. I'm not sure we've got all that logic already in, so this patch might end up a lot bigger than just adding a few parser lines.</div>
<div><br></div><div>Ultimately, I'm not against it, but I'd be a lot more comfortable if I saw lots of tests and lots of people looking at it (from different angles), just to make sure we're not missing anything obvious and introducing major regressions because of syntactic sugar.</div>
<div><br></div><div>cheers,</div><div>--renato</div></div></div></div>