On Fri, Mar 3, 2017 at 12:30 PM, Jakub Jelinek wrote:
>> Regarding the implementation, I'd rather see another flag for
>> i386-builtin.def entries, where we can mark if matching memory operand
>> is allowed. The expander can then look at the flag, and do some
>> special magic.
>
> I think maintai
On Fri, Mar 03, 2017 at 12:18:09PM +0100, Uros Bizjak wrote:
> > as the constraint require that both operands aren't memory, shall I create a
> > patch for that? This is the first category below.
>
> Yes. Although expander takes care not to generate two memory
> references, combine can propagate
On Fri, Mar 3, 2017 at 11:35 AM, Jakub Jelinek wrote:
> On Fri, Mar 03, 2017 at 09:10:03AM +0100, Uros Bizjak wrote:
>> > Or are there any define_insn/define_expand where it is desirable to have
>> > both input and output operand a MEM (and does it have to be matching)?
>> > For various scalar bin
On Fri, Mar 03, 2017 at 09:10:03AM +0100, Uros Bizjak wrote:
> > Or are there any define_insn/define_expand where it is desirable to have
> > both input and output operand a MEM (and does it have to be matching)?
> > For various scalar binary and unary expanders the backend already uses a
> > help
On Thu, Mar 2, 2017 at 10:44 PM, Jakub Jelinek wrote:
> Hi!
>
> For -O1 and above, we force all operands and targets of x86 builtins into
> registers during expansion, because we expect combiner will do its job.
> But for -O0, we try to keep them in MEM if the predicate allows it, we just
> make s
