This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc] multi-word subreg lowering pass


Am Samstag, 7. Mai 2005 05:33 schrieb Richard Henderson:
> I hadn't posted this yet because I've yet to show real measurable
> improvements in long long arithmetic on x86.  I suspect that I
> won't be able to show this until we have a new register allocator.
>
> I'd also planned to restructure this so that it uses recog_data to
> replace values in real operands, rather than replacing subregs
> wherever they may be found.
>
> However, it may be that it's good enough to help the problems that
> AVR is having.  If so, I'll go ahead with the rewrite to recog_data.
>
> The Object is to replace (reg:LARGE X) with a set of (reg:WORD Yi).
> We do this when X is only used in decomposible contexts.  Such
> contexts are (1) subregs smaller than or equal to word sized and
> (2) in a decomposible moves.
>
> If the target leaves logical arithmetic to the middle end, this
> means that the posted example,
>
> 	long long foo(int x, long long y)
> 	{
> 	  return x & y;
> 	}
>
> will decompose to
>
> 	(set (reg:SI 100) (reg:SI x))
> 	(set (reg:SI 101) (const_int 0))
> 	(set (reg:SI 102) (and:SI (reg:SI 100) (reg:SI ylow)))
> 	(set (reg:SI 103) (and:SI (reg:SI 101) (reg:SI yhigh)))
> 	(set (reg:SI eax) (reg:SI 102))
> 	(set (reg:SI edx) (reg:SI 103))
>
> which after cse and combine will be just perfect.
>
> Where it fails is when the target has patterns that take multi-word
> inputs.  In this case we have to stop and leave the data in the
> multi-word pseudo.  This approach does have the advantage of being
> able to work incrementally, though it's also true that incomplete
> conversion can hurt.
>
>
>
> r~
Hello Richard,

Thank you for posting this! ... I will have to study it in more detail, but 
IIUC now you have just been implementing the functionality, I have been 
desireing quite some time  :-) (I used to refer to it as "atomize" pass). I 
will go through your patch. I am confident that with it, one could get 
significant improvement for the AVR target. This will, however, probably take 
a couple of weeks, since IIUC, one would have to implement major 
rearrangements in the avr back-end so that after expand we are actually 
having RTL that your decomposer pass can work on. With the present monolithic 
instructions, I would not expect any improvement.

Best thanks again Yours,

BjÃrn


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]