Hello all,
I am porting GCC 4.5.1 for a private target. For one particular test
reloading pass is being asked to reload the following instruction:
(insn 45 175 46 11 pr20601-1.c:90 (set (reg/f:PQI 3 g3 [70])
(mem/f:PQI (pre_inc:PQI (reg/f:PQI 1 g1 [orig:55 prephitmp.16
] [55])) [2 S1 A32]
On 11/02/11 09:46, Mohamed Shafi wrote:
How can i overcome this failure? Can some one suggest a solution?
Have you defined TARGET_LEGITIMATE_ADDRESS_P and also BASE_REG_CLASS
correctly for your target?
On 11 February 2011 15:28, Paulo J. Matos wrote:
>
>
> On 11/02/11 09:46, Mohamed Shafi wrote:
>>
>> How can i overcome this failure? Can some one suggest a solution?
>>
>
>
> Have you defined TARGET_LEGITIMATE_ADDRESS_P and also BASE_REG_CLASS
> correctly for your target?
>
>
Yes, I have. Regis
Hi,
On Darwin, we have a number of gcc.c-torture fails reported for both
ppc and i386 which are bogus (nothing to do with gcc - but simply
warning output from a system tool).
For dg-based tests these are pruned - I wonder if it would be worth
adding a prune capability to the torture suites
Hi,
I just noticed something very surprising. There's a clause in
general_operand (recog.c):
if (! volatile_ok && MEM_VOLATILE_P (op))
return 0;
Oh... so, a MEM_VOLATILE_P is _not_ a general operand? Why? This is also
not referred to in the documentation of general operand so it
> I just noticed something very surprising. There's a clause in
> general_operand (recog.c):
>
> if (! volatile_ok && MEM_VOLATILE_P (op))
> return 0;
>
> Oh... so, a MEM_VOLATILE_P is _not_ a general operand? Why? This is also
> not referred to in the documentation of general operand
Suppose I have two insns, one reserving (A|B|C), and the other reserving
A. I'm observing that when the first one is scheduled in an otherwise
empty state, it reserves the A unit and blocks the second one from being
scheduled in the same cycle. This is a problem when there's an
anti-dependence of c
On 11/02/11 12:03, Eric Botcazou wrote:
if (! volatile_ok&& MEM_VOLATILE_P (op))
return 0;
.
It's more of the other way around: MEM_VOLATILE_P is a general operand unless
explicitly requested via init_recog_no_volatile. Some passes, like combine,
don't track the volatileness o
On Fri, 11 Feb 2011, Bernd Schmidt wrote:
> Suppose I have two insns, one reserving (A|B|C), and the other reserving
> A. I'm observing that when the first one is scheduled in an otherwise
> empty state, it reserves the A unit and blocks the second one from being
> scheduled in the same cycle. T
On 02/11/2011 02:13 PM, Alexander Monakov wrote:
> Could you please clarify a bit: would the modified behavior match what your
> target CPU does? The current behavior matches CPUs without lookahead in
> instruction dispatch: the first insn goes to the first matching execution
> unit (A), the secon
Hi,
On Fri, 11 Feb 2011, Paulo J. Matos wrote:
> On 11/02/11 12:03, Eric Botcazou wrote:
> > > if (! volatile_ok&& MEM_VOLATILE_P (op))
> > > return 0;
> >.
> >
> > It's more of the other way around: MEM_VOLATILE_P is a general operand
> > unless
> > explicitly requested via init
Hi,
According to me at this moment the scheduler does not support your needs.
I was confronted with a similar problem as yours and I solved it by
implementing the TARGET_SCHED_DFA_NEW_CYCLE hook. Inside of the function which
supports this hook I choose/set the insn reservation that makes possib
On 11/02/11 13:56, Michael Matz wrote:
The piece of code you quoted also is conditional on volatile_ok. Connect
that with what Eric said.
Thanks Michael, I guess I should sleep before asking anything else. Now
I understand what Eric said.
Thanks. Another question. Is there any plan to vectorize
the loops like the following ones?
for (i=127; i>=0; i--) {
x[i] = y[i] + z[i];
}
I found that GCC trunk still cannot handle negative step
for store. Even it can, it won't be efficient by introducing
redundant permutations o
On 2/11/2011 7:30 AM, Bingfeng Mei wrote:
Thanks. Another question. Is there any plan to vectorize
the loops like the following ones?
for (i=127; i>=0; i--) {
x[i] = y[i] + z[i];
}
When I last tried, the Sun compilers could vectorize such loops
efficiently (for fairly short
Le vendredi 11 février 2011 à 13:33 +0100, Bernd Schmidt a écrit :
> Suppose I have two insns, one reserving (A|B|C), and the other reserving
> A. I'm observing that when the first one is scheduled in an otherwise
> empty state, it reserves the A unit and blocks the second one from being
> schedule
On 02/11/2011 07:43 PM, Frédéric RISS wrote:
> Le vendredi 11 février 2011 à 13:33 +0100, Bernd Schmidt a écrit :
>> Suppose I have two insns, one reserving (A|B|C), and the other reserving
>> A. I'm observing that when the first one is scheduled in an otherwise
>> empty state, it reserves the A un
"Paulo J. Matos" writes:
> On 10/02/11 16:04, Ian Lance Taylor wrote:
>> Bother. I've encountered that problem before and I think I used a
>> sledgehammer (a local patch). It's definitely a bug that gcse doesn't
>> consider costs.
>>
>
> I think I might try also patching my local gcc. I guess t
On Thu, Feb 10, 2011 at 3:13 AM, Jonathan Wakely wrote:
> On 10 February 2011 05:18, Quentin Neill wrote:
>> On Wed, Feb 9, 2011 at 2:42 AM, Jonathan Wakely
>> wrote:
>>> On 9 February 2011 08:34, Sebastian Pop wrote:
For example x264 defines CFLAGS="-O4 -ffast-math $CFLAGS", and so
>>
On 02/11/2011 07:33 AM, Bernd Schmidt wrote:
Suppose I have two insns, one reserving (A|B|C), and the other reserving
A. I'm observing that when the first one is scheduled in an otherwise
empty state, it reserves the A unit and blocks the second one from being
scheduled in the same cycle. This is
On Fri, Jan 28, 2011 at 01:11:10AM +, Joseph S. Myers wrote:
> Here is a concrete list I propose for deprecation in 4.6; please send
> any other suggestions...
score-* doesn't have a maintainer and score-elf couldn't build libgcc
last I checked (it was also mentioned in your previous message).
On Fri, 11 Feb 2011, Nathan Froyd wrote:
> On Fri, Jan 28, 2011 at 01:11:10AM +, Joseph S. Myers wrote:
> > Here is a concrete list I propose for deprecation in 4.6; please send
> > any other suggestions...
>
> score-* doesn't have a maintainer and score-elf couldn't build libgcc
> last I che
22 matches
Mail list logo
