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

[Jim Grosbach]

FWIW, I’ve long had big concerns about how we model addressing modes. I don’t have any magic bullet solutions, unfortunately, but the sorts of things you’re talking about here are in the same general direction as what I’ve been thinking. The assembler wants to talk about the individual operands and doesn’t much care that they’re part of an overarching “addressing mode operand”. CodeGen is the other way around.

-Jim

On May 13, 2014, at 12:20 AM, Tim Northover <t.p.northover at gmail.com> wrote:

> 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