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: i386.c: don't allow ASHIFTs in addresses


> On Wed, Jan 09, 2002 at 11:56:59AM +0100, Entwickler Michael Matz wrote:
> > the patch corrects the testcase below.  ASHIFTs are not allowed in
> > addresses and shouldn't be handled by ix86_decompose_address.  The part
> > which this was supposed to handle (recognizing arguments for lea) is
> > actually handled by a splitter.
> 
> No, I'm fairly certain that I added this for a reason.
> 
> Yes,

> 
> At -O0, the splitter will not be run, alternative 1 selected.
> In branch shortening we'll ask for the length of the insn,
> which is computed based on the type, which will call 
> decompose address so that we can compute the size of the
> address.
> 
> You'll have to find another way to prevent ASHIFT from being
> used in straight addresses.  Or figure out why its failing --
> I can't think of any reason off-hand why it should
The problem is that (ashift X Y) address is accepted but 
(plus (ashift X Y) Z) not and splitters turns the first to second.
I really don't think doing so is good idea - firstly it makes addresses
to be (in rare occasions) in "wrong" form confusing cse/combine/reload.
The other problem I see is that lea pattern will accept simple shifts
that will prevent combine/cse from adding the clobber when shift is synthetized
forcing lea to be used.

Perhaps we can allow decompose address to do the job, but check for
presence of ASHIFT in legitimate_address?
Or make cse to legitimize the address more activly than it is doing now
to always convert SHIFT to MULT, but I am not certain this is not going
to break something else.

Honza
> 
> 
> r~


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