<div dir="ltr">Hi Joerg,<div><br></div><div>> It breaks compatibility with existing code.</div><div><br></div><div>But if the existing code you're referring to is incorrect, I don't see the issue. Incorrect code is incorrect code, and we don't keep compiler bugs around to satisfy legacy programs. Personally I don't see this as different to any other compiler bug.</div>
<div><br></div><div>>  I still haven't heard an argument for why it is needed.</div><div><br></div><div>The toolchain is not in compliance with the reference manuals for post-v6 targets, AIUI.</div><div><br></div><div>
Basically I agree with Tim and Artyom - sorry! Do you still want to push for reversion of this patch?</div><div><br></div><div>Cheers,</div><div><br></div><div>James</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 2 December 2013 00:06, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sun, Dec 01, 2013 at 10:39:48AM +0000, Tim Northover wrote:<br>
> > This commit breaks valid assembler sources that use MCR/MRC explicitly<br>
> > in place of the (newer) NP/NEON forms.<br>
><br>
> I believe those sources are (strictly) invalid on v6 and above. All<br>
> coprocessor instructions begin with "if coproc in '101x' then SEE<br>
> 'floating-point instructions", terminology that's used elsewhere for<br>
> cases which don't permit overlap.<br>
><br>
> > I don't see the point of this<br>
> > change and therefore would like to see it reverted on trunk and 3.4.<br>
><br>
> From Artyom's point of view, it's probably making sure LLVM adheres to<br>
> the reference manuals. For the writers of the reference manuals, I<br>
> suspect the problem is running out of encoding space and having to use<br>
> (say) MRC-type encodings for instructions that have absolutely nothing<br>
> MRC-like about them -- better to completely forbid the misleading<br>
> forms than leave confusion.<br>
><br>
> Personally, I don't see the argument for keeping this as an alias on<br>
> post-v5 architectures. I can't think of a use that wouldn't be better<br>
> served by writing it in terms of the real FP instructions.<br>
<br>
</div>It breaks compatibility with existing code. As I said, I still haven't<br>
heard an argument for why it is needed. Deprecate them and don't add new<br>
aliases -- fine. But removing something that has been accepted for a<br>
long time?<br>
<span class="HOEnZb"><font color="#888888"><br>
Joerg<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>