Sent from my iPhone
On Jul 28, 2007, at 4:36 PM, Christopher Lamb <[EMAIL PROTECTED]
> wrote:
On Jul 28, 2007, at 2:26 PM, Evan Cheng wrote:
On Jul 28, 2007, at 11:52 AM, Christopher Lamb <[EMAIL PROTECTED]
> wrote:
On Jul 28, 2007, at 1:48 AM, Evan Cheng wrote:
Very cool! I need to read it more carefully.
But I see you are lowering zext to a single insert_subreg. Is
that right? It won't zero out the top part, no?
It's only lowering (zext i32 to i64) to an insert_subreg on x86-64
where all writes to 32-bit registers implicitly zero-extend into
the upper 32-bits.
I know. But thy mismatch semantically. A insert_subreg to the lower
part should not change the upper half. I think this is only legal
for anyext.
On x86-64 the semantics of a 2 operand i32 insert_subreg is that the
input super-value is implicitly zero. So in this sense the insert
isn't changing the upper half, it's just that the upper half is
being set to zero implicitly rather than explicitly. If you'll
notice the insert_subreg is a two operand (implicit super value) not
a three operand version. If the insert were the three operand
version, and the super value as coming from an implicit def I'd
agree with you, but it's not.
Ok, let's step back for a second. There are a couple of issues that
should be addressed. Plz help me understand. :)
1: Semantics of insert_subreg should be the same across all targets,
right?
2: two operant variant of insert_subreg should mean the superreg is
undef. If you insert a value into a low part, the rest of the superreg
is still undef.
3: why is there a two operant variant in the first place? Why not use
undef for the superreg operant?
4: what's the benefit of isel a zext to insert_subreg and then xform
it to a 32-bit move? Why not just isel the zext to the move? It's not
legal to coalesce it away anyway.
Evan
Also the current behavior is to use a 32-bit mov instruction for
both zeroext and for anyext, I don't see how this is any different.
--
Chris
Sent from my iPhone
On Jul 28, 2007, at 12:17 AM, Christopher Lamb <[EMAIL PROTECTED]
> wrote:
This patch changes the X86 back end to use the new subreg
operations for appropriate truncate and extend operations. This
should allow regression testing of the subreg feature going
forward, as it's now used in a public target.
The patch passed DejaGnu and all of SingleSource on my x86
machine, but there are changes for x86-64 as well which I
haven't been able to test. Output assembly for x86-64 appears
sane, but I'd appreciate someone giving the patch a try on their
x86-64 system. Other 32-bit x86 testing is also appreciated.
Thanks
--
Christopher Lamb
<x86_subregs.patch>
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
--
Christopher Lamb
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
--
Christopher Lamb
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
