|
From: Jeremy F. <je...@go...> - 2002-12-14 02:41:58
|
I'm wondering why AND and OR don't get to take anything but TempReg
args. From inspecting some largish chunks of code (mozilla), almost all
the AND instructions are with a constant.
Is it something to do with the special properties of AND and OR
regarding memcheck verification?
Speaking of which, I presume the intent behind generating:
movl $0, %reg
xorl %reg, %reg
is to break the dependency on any previous value of %reg. Unfortunately
it actually generates the mov in the final code. I wonder if a better
solution is add a DEFINE UInstr which defines (ie, is considered to
write to) its argument without actually generating any code.
I've hacked up a patch to treat AND and OR the same way as the rest of
that group of instructions, but it is falling over in regalloc with
memcheck.
J
|
|
From: Julian S. <js...@ac...> - 2002-12-14 03:43:42
|
On Saturday 14 December 2002 2:41 am, Jeremy Fitzhardinge wrote: > I'm wondering why AND and OR don't get to take anything but TempReg > args. From inspecting some largish chunks of code (mozilla), almost all > the AND instructions are with a constant. > > Is it something to do with the special properties of AND and OR > regarding memcheck verification? Yes, it's because it makes it a bit simpler to generate the wierd bits of code needed to do the memcheck AND/OR stuff. > Speaking of which, I presume the intent behind generating: > > movl $0, %reg > xorl %reg, %reg The problem here is that an original-code xorl %reg, %reg both makes %reg = 0 and does something or other with the flags. Treating it as if it was preceded by a literal load of zero stops memcheck yelping if %reg is undefined before the xor. Retaining the xor means I don't have to figure out what to set the flags to following the mov of $0. J |
|
From: Jeremy F. <je...@go...> - 2002-12-14 09:08:51
|
On Fri, 2002-12-13 at 19:51, Julian Seward wrote:
> > I'm wondering why AND and OR don't get to take anything but TempReg
> > args. From inspecting some largish chunks of code (mozilla), almost all
> > the AND instructions are with a constant.
> >
> > Is it something to do with the special properties of AND and OR
> > regarding memcheck verification?
>
> Yes, it's because it makes it a bit simpler to generate the wierd
> bits of code needed to do the memcheck AND/OR stuff.
OK, I worked all this through. I changed it so that AND and OR are
treated the same way as ADD/SUB/XOR/etc, but when generating code for
ImproveAND/ORn_TQ it copies the value into a TempReg, so I didn't have
to go through and touch all that.
This was worth a couple of percent with --skin=none on gcc.
> > Speaking of which, I presume the intent behind generating:
> >
> > movl $0, %reg
> > xorl %reg, %reg
>
> The problem here is that an original-code xorl %reg, %reg both
> makes %reg = 0 and does something or other with the flags. Treating
> it as if it was preceded by a literal load of zero stops memcheck
> yelping if %reg is undefined before the xor. Retaining the xor
> means I don't have to figure out what to set the flags to following
> the mov of $0.
As an experiment, I added a DEFINE UInstr which simply has the effect of
treating a register as defined. This makes the regalloc happy (since
the TempReg has been written before use), and memcheck happy (since the
xor ends up with a defined result), but it doesn't generate any more
code. I also added cases for SBB and SUB. SUB is another recommended
sequence for zeroing things, but I didn't see it in practice; SBB %reg,
%reg is surprisingly common (I guess as an idiom to move CF into a
register, though I'm not sure what for).
J
|