[llvm-commits] [PATCH] Execution domain support for VMOV and VLDR
Tim Northover
t.p.northover at gmail.com
Tue Aug 28 05:04:39 PDT 2012
On Mon, Aug 20, 2012 at 12:04 PM, Tim Northover <t.p.northover at gmail.com> wrote:
>> I was thinking - is it possible to somehow make code generic? And not
>> to do error-prone manual change of instructions...
>
> Hmm. The conversion does feel particularly error-prone. I think the
> transformations are probably too dissimilar to automate though, even
> within a single target. We could almost certainly improve things so
> that a BuildMI is used to make a fresh instruction in all cases. We
> might be able to move the implicit operand transfer into generic code,
> but that almost feels more fragile to me: it's just asking for a case
> to slip through where the default behaviour is unacceptable but
> because it's hidden away no-one realises.
>
> What did you have in mind?
Ok, I've implemented a version of what I described above so we'll at
least have something to discuss. I've not ported my original patches
over to this new framework yet, but is this acceptable?
I think it makes X86 slightly uglier (all instructions there had the
correct operands already, so the *only* thing happening was a
setDesc), but ARM quite a bit better (people are used to seeing
BuildMIs and know information isn't being hidden). Overall it probably
is an improvement. I'm still slightly concerned about the fragility of
hidden operand transfer, but in my opinion the alternative would be
ugly enough that the whole refactor is a net loss.
There's no regression testing because it's a refactor so should be
covered by existing tests.
What do you think? (Or anyone else?)
Tim.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refactor-domains.diff
Type: application/octet-stream
Size: 11096 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120828/49378e42/attachment.obj>
More information about the llvm-commits
mailing list