This is the mail archive of the gcc@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: Analysis of high priority PR c/2454


>  In message <200207021848.LAA11049@atrus.synopsys.com>, Joe Buck writes:
>  >But wouldn't such a solution pessimize code in some cases?  If we know,
>  >because of the way that the subreg was generated, that it already exists
>  >in zero-extended or sign-extended form (e.g. because a byte read from
>  >memory on the processor always generates such a form in the register),
>  >then requiring the compiler to generate an explicit zero-extend or sign
>  >extend would be wasted computation.
> Not really.  For example, we could create patterns which matched the
> load-with-{zero,sign} extension.
> 
> So the initial RTL generation would create:
> 
> (set (reg:QI temp) (mem:QI (address))
> (set (reg:SI target) (zero_extend:SI (reg:QI temp)))
> 
> 
> Combine would then turn that into:
> 
> 
> (set (reg:SI target) (zero_extend:SI (mem:QI (address))))
> 
> 
> No extra registers, no (*&!@#$ paradoxical subregs and the RTL shows
> very clearly what's really happening.  No hidden zero/sign extensions
> behind our backs.
> 
> If that's a pain (say due to reload weirdness), it would be pretty
> simple to create an optimizer which ran after reload which was 
> designed to zap redundant sign/zero extensions.
> 
> jeff
> 

I seem to remember trying once to make the expander for movqi on the ARM 
generate

(set (reg:SI) (zero_extend:SI (mem:QI (address))))

(set (reg:QI) (subreg:QI (reg:SI) 0))

Which is an even more accurate description of what happens, and the subreg 
is a proper one.

However, I can't remember why I never committed the code; perhaps the 
results were worse.

R.


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