[PATCH] [ARM64] Fix the misleading diagnostic on bad extend amount of reg+reg addressing mode.

Kevin Qin kevinqindev at gmail.com
Tue May 13 00:52:49 PDT 2014


Hi Tim,

Patch is commited at r208669. Thanks for your understanding. I was just
trying to provide more precise diagnostics to get end-user easily use our
backend. Also, I'm very happy to see you're going to solve this from root
cause:)

Best Regards,
Kevin


2014-05-13 15:20 GMT+08:00 Tim Northover <t.p.northover at gmail.com>:

> Hi again,
>
> > If you really want more accurate diagnostics then we need to do in some
> > way that actually improves the code quality, not just the diagnostic
> quality.
>
> Bradley's been encountering similar issues with load/store
> diagnostics, and has mentioned that a large part of the problem is
> that so much complexity is put into a single conglomerate operand.
>
> AArch64 has split up the load/store instructions much more than ARM64,
> allowing more focussed diagnostics. I think that went too far (the
> patterns are an unmaintainable mess), but some middle ground might
> give us both a neater assembler and more focussed diagnostics when
> things go wrong.
>
> From what I remember, the reason AArch64 had to split things up as
> much as it did is that once you go beyond a single operand that can be
> handled by a ComplexPat, you need to split *everything* up to be able
> to use the instructions. This multiplies the number of instructions
> greatly.
>
> Very similar concerns (but on a slightly simpler level) apply to the
> register-offset arithmetic & logical operations. I'm wondering if a
> more flexible ComplexPatFrag, capable of distributing its results to
> more than a single Operand, might allow us the best of both worlds:
> few instructions, but each with many operands so that the last failure
> point actually gives us useful information.
>
> I think I might try to implement that today (only on arith/logical for
> now though; load/store would be a big project). I'll let you know how
> it goes.
>
> Cheers.
>
> Tim.
>
> (duplicate to llvm-commits).
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>



-- 
Best Regards,

Kevin Qin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140513/29aefb27/attachment.html>


More information about the llvm-commits mailing list