This is the mail archive of the 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: IRA: matches insn even though !reload_in_progress

On Wed, Jul 13, 2011 at 01:42:29PM +0200, Georg-Johann Lay wrote:
> All the trouble arises because there is no straight forward way to
> write the right insn condition, doesn't it?
> Working around like that will work but it is obfuscating the code, IMHO.

Given I don't know the AVR port, I don't know what the right condition is.  I
was just guessing from the patterns you provided.

> Is there a specific reason for early-clobber ind *wrapper?

You could instead put (clobber (match_scratch)) in the insn, and not split it
until after reload.

> As *wrapper is not a proper move, could this produce move-move-sequences?
> These would have to be fixed in peep2 or so.

In theory the register allocator will eliminate the normal move, and just use
the wrapper.

> This is the missing part, and if gcc learns something like
> !ira_in_progress or !split1_completed in the future, the cleanup will
> be minimal and straight forward.  The code is obvious and without
> obfuscation:

I tend to think a few more <xxx>_in_progress and <xxx>_completed flags would be
helpful, particularly ira_in_progress or make reload_in_progress be set by ira.
You are probably the first person to run into this.  The question is how many
do we want and need?

Note, a few years ago, this type of splitting was not possible.  You had to
have all of the match_scratch'es that you would need allocated in the RTL
generation pass.  Being able to allocate new psuedos before the split1 pass
certainly makes things easier to do, but there are always things that could be
done better.

> bool
> avr_gate_split1 (void)
> {
>   if (current_pass->static_pass_number
>       < pass_match_asm_constraints.pass.static_pass_number)
>     return true;
>   return false;
> }
> I choose .asmcons because it runs between IRA and split1,
> and because I observed that pass numbers are fuzzy;
> presumably because sub-passes like df etc.

I'm not a big fan of this.  I think it would be better to just add
ira_in_progress and a few others as needed.

Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA	fax +1 (978) 399-6899

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