On 04/13/2018 05:26 PM, Segher Boessenkool wrote:
Hi!
On Fri, Apr 13, 2018 at 04:43:02PM -0400, Vladimir Makarov wrote:
On 04/13/2018 03:58 PM, Alexander Monakov wrote:
Here's another compact variant:
regno = reg_renumber[regno];
if (regno < 0)
regno = cl ==
Hi!
On Fri, Apr 13, 2018 at 04:43:02PM -0400, Vladimir Makarov wrote:
> On 04/13/2018 03:58 PM, Alexander Monakov wrote:
> >Here's another compact variant:
> >
> > regno = reg_renumber[regno];
> > if (regno < 0)
> > regno = cl == NO_REGS ? -1 : ira_class_hard_regs[cl][1];
> >
>
On 04/13/2018 03:58 PM, Alexander Monakov wrote:
On Fri, 13 Apr 2018, Jakub Jelinek wrote:
if (reg_renumber[regno] >= 0)
regno = reg_renumber[regno];
else
regno = cl == NO_REGS ? -1 : ira_class_hard_regs[cl][1];
or
regno = (reg_renumber[reg
On Fri, 13 Apr 2018, Jakub Jelinek wrote:
> if (reg_renumber[regno] >= 0)
> regno = reg_renumber[regno];
> else
> regno = cl == NO_REGS ? -1 : ira_class_hard_regs[cl][1];
> or
> regno = (reg_renumber[regno] >= 0
> ? reg_renumber[regno]
>
On Fri, Apr 13, 2018 at 03:29:47PM -0400, Vladimir Makarov wrote:
> The attached patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79916
>
> The PR is about LRA cycling on some tests when SD data are used. The
> problem was in that actual assigned reg to pseudo was not in the pseu
On Tue, Jun 5, 2012 at 3:13 PM, Edmar wrote:
> The patch I submitted had an omission. I failed to regenerate
> rs6000-tables.opt
> (Sorry, I misunderstood gcc_update --touch instructions)
> OK to commit the update ?
>
> 2012-06-05 Edmar Wienskoski
>
> * config/rs6000/rs6000-tables.opt: Regene
The patch I submitted had an omission. I failed to regenerate
rs6000-tables.opt
(Sorry, I misunderstood gcc_update --touch instructions)
OK to commit the update ?
2012-06-05 Edmar Wienskoski
* config/rs6000/rs6000-tables.opt: Regenerated.
On 06/04/2012 08:45 PM, David Edelsohn wrote:
T
On Fri, Jun 1, 2012 at 11:57 AM, Edmar wrote:
> Freescale would like to contribute these patches to gcc.
>
> It enables gcc for the new Freescale 64 bit cores. It creates a pipeline
> description, and set proper default flags for the e5500 and e6500 cores.
>
> Some Altivec extensions for e6500 wil
Freescale would like to contribute these patches to gcc.
It enables gcc for the new Freescale 64 bit cores. It creates a pipeline
description, and set proper default flags for the e5500 and e6500 cores.
Some Altivec extensions for e6500 will be submitted as a separate process.
The patch was reg
On Wed, May 23, 2012 at 10:18 AM, Edmar wrote:
> David, Michael,
>
> Thanks for the feedback.
> If you don't object, I will relay the message to the designers.
>
> Meanwhile I have to work with the cards I have, so...
> I will break the patch in three parts:
> - One that includes the very basic, s
David, Michael,
Thanks for the feedback.
If you don't object, I will relay the message to the designers.
Meanwhile I have to work with the cards I have, so...
I will break the patch in three parts:
- One that includes the very basic, scheduling etc.
- One for the Altivec builtins, which I will h
> Regarding the implementation of popcntb, popcntd, and cmpb. Gcc has
> dedicated masks on target_flags for them, but due to shortage of bits,
> those masks controls more than the name implies.
The target flag bits control more than the name implies, but the bits
correspond to published ISA levels
Michael,
Thanks for reviewing the patch and all the suggestions.
I have some questions / comments bellow.
Regards,
Edmar
On 05/17/2012 06:16 PM, Michael Meissner wrote:
In the patch I minimized the number of changes, while not adding
any new mask to target_flags.
While we may get some bits
On Tue, Mar 06, 2012 at 11:44:08AM -0500, Edmar wrote:
> Freescale would like to contribute these patches to gcc.
>
> It enables gcc for the new Freescale 64 bit cores. It creates a pipeline
> description, and set proper default flags for the e5500 and e6500 cores.
>
> Both are 64 bit cores capa
On 04/20/2011 07:52 PM, Segher Boessenkool wrote:
The test and-1.c has wrong logic.
In the formula:
y & ~(y & -y)
The part (y & -y) is always a mask with one bit set, which corresponds
to the least significant "1" bit in y.
The final result is that bit, is set to zero (y & ~mask)
There is no bo
The test and-1.c has wrong logic.
In the formula:
y & ~(y & -y)
The part (y & -y) is always a mask with one bit set, which corresponds
to the least significant "1" bit in y.
The final result is that bit, is set to zero (y & ~mask)
There is no boolean simplification possible, and the compiler alw
16 matches
Mail list logo
