Le jeudi 06 janvier 2011 à 09:29 -0800, Richard Henderson a écrit :
> On 01/06/2011 06:58 AM, Frederic Riss wrote:
> > 136 is a pseudo. I have movdf and movsf patterns that accepts
> > constants.
>
> This one statement is suspicious to me. Do I read from this that
> you have fp move patterns that
On 01/06/2011 06:58 AM, Frederic Riss wrote:
> 136 is a pseudo. I have movdf and movsf patterns that accepts
> constants.
This one statement is suspicious to me. Do I read from this that
you have fp move patterns that accept constants but not registers?
Move patterns are special in that they *mus
Frederic Riss writes:
> On 6 January 2011 17:02, Ian Lance Taylor wrote:
>> Oh yeah, you should never have a subreg of a subreg. That's a bug.
>> Where did that come from?
>
> Oh, that's interesting information! I have a splitter for movdf that
> must be the culprit. I will tighten the split co
On 6 January 2011 17:02, Ian Lance Taylor wrote:
> Oh yeah, you should never have a subreg of a subreg. That's a bug.
> Where did that come from?
Oh, that's interesting information! I have a splitter for movdf that
must be the culprit. I will tighten the split condition to disallow
splitting a s
Frederic Riss writes:
> I use nonimmediate_operand as a movsi destination predicate. I think
> this is pretty standard. But if I follow the code in
> recog.c:general_operand, I can see that it will reject (subreg (subreg
> ...)) which my initial pattern is. So yes, my movsi destination
> predicat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/06/11 03:23, Frederic Riss wrote:
> On 6 January 2011 10:27, Frederic Riss wrote:
>> Hi,
>>
>> I've seen GCC emit many unneeded moves in very simple cases when
>> handling double floating point values. I tracked this down to the
>> lower-subreg
On 6 January 2011 16:14, Ian Lance Taylor wrote:
> Frederic Riss writes:
>> I managed to get thinks going by constraining MODES_TIEABLE_P and
>> adding 2 patterns of the form:
>>
>> [(set (subreg:SI (match_operand:DF 0 "register_operand" "=r") 0)
>> (match_operand 1 "immediate_operand" "i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/06/11 07:58, Frederic Riss wrote:
> On 6 January 2011 15:27, Ian Lance Taylor wrote:
>> Frederic Riss writes:
>>> ../gcc/testsuite/gcc.c-torture/execute/ieee/930529-1.c:27:1: error:
>>> unrecognizable insn:
>>> (insn 45 2 46 2
>>> ../gcc/testsu
Frederic Riss writes:
> 136 is a pseudo. I have movdf and movsf patterns that accepts
> constants. I'm not sure what happens. Also, strictly speaking, the
> unrecognized pattern above is a SI move and not a floating point move,
> isn't it?
Yes, it is.
> I managed to get thinks going by constrai
On 6 January 2011 15:27, Ian Lance Taylor wrote:
> Frederic Riss writes:
>> ../gcc/testsuite/gcc.c-torture/execute/ieee/930529-1.c:27:1: error:
>> unrecognizable insn:
>> (insn 45 2 46 2
>> ../gcc/testsuite/gcc.c-torture/execute/ieee/930529-1.c:2 (set
>> (subreg:SI (subreg:DF (reg/v:DI 136 [ d ])
Frederic Riss writes:
> I tried to limit the lower-subreg pass to splitting integral types by
> constraining MODES_TIEABLE_P. This works for my simple test cases, but
> I get some testsuite regressions of the form:
>
> ../gcc/testsuite/gcc.c-torture/execute/ieee/930529-1.c:27:1: error:
> unrecogn
On 6 January 2011 10:27, Frederic Riss wrote:
> Hi,
>
> I've seen GCC emit many unneeded moves in very simple cases when
> handling double floating point values. I tracked this down to the
> lower-subreg pass that splits DF->DF moves into DF->(2*SI)->DF moves.
> I suppose that the introduced mode
12 matches
Mail list logo
