Re: Try simplifying memory operands during optabs expansion

2011-04-14 Thread Richard Henderson
On 04/14/2011 06:42 AM, Richard Sandiford wrote: > The !side_effects_p check is the only change from last time. > > Tested on x86_64-linux-gnu, this time on a machine set up for building > the 32-bit multilibs. Also tested on arm-linux-gnueabi. OK to install? > > Richard > > > gcc/ > *

Re: Try simplifying memory operands during optabs expansion

2011-04-14 Thread Richard Sandiford
Richard Henderson writes: > On 03/31/2011 03:19 AM, Richard Sandiford wrote: >> * recog.h (insn_operand_data): Add an "allows_mem" field. >> * genoutput.c (output_operand_data): Initialize it. >> * optabs.c (maybe_legitimize_operand_same_code): New function. >> (maybe_legitimiz

Re: Try simplifying memory operands during optabs expansion

2011-04-01 Thread Richard Henderson
On 03/31/2011 03:19 AM, Richard Sandiford wrote: > * recog.h (insn_operand_data): Add an "allows_mem" field. > * genoutput.c (output_operand_data): Initialize it. > * optabs.c (maybe_legitimize_operand_same_code): New function. > (maybe_legitimize_operand): Use it when match

Try simplifying memory operands during optabs expansion

2011-03-31 Thread Richard Sandiford
This is the main change that motivated the less-than-successful optabs interface "cleanup". Tree expansion yields MEMs that are legitimiate memory_operands, but it's not uncommon for some optabs to need a more restricted type of address. This patch records whether operands can be memories, and ma