On Thu, Feb 14, 2019 at 05:30:52PM +0100, Eric Botcazou wrote:
> > Yeah, something like that. It will need some serious testing, to make
> > sure we don't regress (including not regressing what that patch that took
> > them away was meant to do). I can arrange some testing, will you do the
> > pa
> Yeah, something like that. It will need some serious testing, to make
> sure we don't regress (including not regressing what that patch that took
> them away was meant to do). I can arrange some testing, will you do the
> patch though?
I can do the patch and also (correctness) testing for 32-b
On Tue, Feb 12, 2019 at 11:55:24AM +0100, Eric Botcazou wrote:
> > No, we should allow both integer and floating point insns for integer stores
> > always. We just get the cost estimates slightly wrong now, apparently.
>
> Note that my proof of concept patch doesn't disallow them either... So wh
> No, we should allow both integer and floating point insns for integer stores
> always. We just get the cost estimates slightly wrong now, apparently.
Note that my proof of concept patch doesn't disallow them either... So what
do you suggest? Just putting back the '*' modifiers in the DI patt
On Mon, Feb 11, 2019 at 10:07:44AM +0100, Eric Botcazou wrote:
> > You make an arbitrary distinction between certain CPUs and duplicate
> > patterns based on that.
>
> Sure, somewhat arbitrary, but that's a proof of concept and IMO better than
> treating every processor the same way. The alterna
> You make an arbitrary distinction between certain CPUs and duplicate
> patterns based on that.
Sure, somewhat arbitrary, but that's a proof of concept and IMO better than
treating every processor the same way. The alternative would be to complicate
further the existing patterns by means of th
On Fri, Feb 08, 2019 at 11:46:37AM +0100, Eric Botcazou wrote:
> > Backporting this is okay. (It was not done because it does not affect
> > correctness). What is the "almost", btw?
>
> The predicate of operand #0 of movdi_internal32 is
> rs6000_nonimmediate_operand
> on the 7 branch and nonim
> Backporting this is okay. (It was not done because it does not affect
> correctness). What is the "almost", btw?
The predicate of operand #0 of movdi_internal32 is rs6000_nonimmediate_operand
on the 7 branch and nonimmediate_operand on the 8 branch and later.
> (In https://gcc.gnu.org/ml/gcc
Hi!
On Wed, Feb 06, 2019 at 11:08:44PM +0100, Eric Botcazou wrote:
> as reported e.g. at https://gcc.gnu.org/ml/gcc-help/2018-11/msg00038.html,
> the
> 7 series of compilers started to use FP instructions for simple 64-bit
> integer
> loads/stores in unexpected ways. Consider:
> The differ
Hi,
as reported e.g. at https://gcc.gnu.org/ml/gcc-help/2018-11/msg00038.html, the
7 series of compilers started to use FP instructions for simple 64-bit integer
loads/stores in unexpected ways. Consider:
uint64_t var;
void foo1 (uint64_t *p)
{
var = *p;
}
void foo2 (uint64_t *p)
{
*p =
10 matches
Mail list logo
