Eric Botcazou wrote:
>> Following the recent comments by Eric, the patch now sketches the
>> following setup:
>>
>> If multi-lib is wanted:
>> configure --with-cpu=leon ... : creates multilib-dir soft|v8
>> combinations using [-msoft-float|-mcpu=sparcleonv8] (MULTILIB_OPTIONS =
>> msoft-fl
> Is the list above an indication that you are already finished with
> the modifications? :-)
> Can you give me a note, otherwise I'll create a new patch that implements
> the scheme you suggested.
>
Sorry, I didnt note the attachment that is already your implementation.
I thought it was the ol
On Tue, Nov 23, 2010 at 9:09 PM, Joern Rennecke wrote:
> If we changed BITS_PER_UNIT into an ordinary piece-of-data 'hook', this
> would not only cost a data load from the target vector, but would also
> inhibit optimizations that replace division / modulo / multiply with shift
> or mask operation
On Nov 24, 2010, at 6:45 AM, Richard Guenther wrote:
> On Tue, Nov 23, 2010 at 9:09 PM, Joern Rennecke wrote:
>> If we changed BITS_PER_UNIT into an ordinary piece-of-data 'hook', this
>> would not only cost a data load from the target vector, but would also
>> inhibit optimizations that replace
Quoting Richard Guenther :
Well. Some things really ought to stay as macros. You can always
error out if a multi-target compiler would have conflicts there at
configure time.
So what are we going to do about all the tree optimizers and frontends that
use BITS_PER_UNIT?
Should they all includ
On Tuesday 23 November 2010 20:09:52, Joern Rennecke wrote:
> If we changed BITS_PER_UNIT into an ordinary piece-of-data 'hook', this
> would not only cost a data load from the target vector, but would also
> inhibit optimizations that replace division / modulo / multiply with shift
> or mask opera
On 30 October 2010 05:45, Joern Rennecke wrote:
> Quoting Mohamed Shafi :
>
>> On 29 October 2010 00:06, Joern Rennecke
>> wrote:
>>>
>>> Quoting Mohamed Shafi :
>>>
Hi,
I am doing a port in GCC 4.5.1. For the port
1. there is only (reg + offset) addressing mode only when
Quoting Pedro Alves :
On Tuesday 23 November 2010 20:09:52, Joern Rennecke wrote:
If we changed BITS_PER_UNIT into an ordinary piece-of-data 'hook', this
would not only cost a data load from the target vector, but would also
inhibit optimizations that replace division / modulo / multiply with s
On Wed, Nov 24, 2010 at 1:56 PM, Joern Rennecke wrote:
> Quoting Richard Guenther :
>
>> Well. Some things really ought to stay as macros. You can always
>> error out if a multi-target compiler would have conflicts there at
>> configure time.
>
> So what are we going to do about all the tree opt
Quoting Richard Guenther :
On Wed, Nov 24, 2010 at 1:56 PM, Joern Rennecke wrote:
So what are we going to do about all the tree optimizers and frontends that
use BITS_PER_UNIT?
Tree optimizers are fine to use target macros/hooks, and I expect
use will grow, not shrink.
Hooks are fine, as l
On Wed, Nov 24, 2010 at 3:12 PM, Joern Rennecke wrote:
> Quoting Richard Guenther :
>
>> On Wed, Nov 24, 2010 at 1:56 PM, Joern Rennecke
>> wrote:
>>>
>>> So what are we going to do about all the tree optimizers and frontends
>>> that
>>> use BITS_PER_UNIT?
>>
>> Tree optimizers are fine to use t
On Wed, Nov 24, 2010 at 09:17, Richard Guenther
wrote:
> And we don't want to pay the overhead of hookization every target
> dependent constant just for the odd guys who want multi-target
> compilers that have those constants differing.
I would like to know how much this overhead really amounts
On Wed, Nov 24, 2010 at 3:33 PM, Diego Novillo wrote:
> On Wed, Nov 24, 2010 at 09:17, Richard Guenther
> wrote:
>
>> And we don't want to pay the overhead of hookization every target
>> dependent constant just for the odd guys who want multi-target
>> compilers that have those constants differin
On Wed, Nov 24, 2010 at 09:37, Richard Guenther
wrote:
> Well. Long term. Hookizing constants is easy - before proceeding
> with those (seemingly expensive) ones I'd like to see all the _hard_
> target macros converted into hooks. If there are only things like
> BITS_PER_UNIT left we can talk
On Wednesday 24 November 2010 13:45:40, Joern Rennecke wrote:
> Quoting Pedro Alves :
>
> > On Tuesday 23 November 2010 20:09:52, Joern Rennecke wrote:
> >> If we changed BITS_PER_UNIT into an ordinary piece-of-data 'hook', this
> >> would not only cost a data load from the target vector, but woul
I think I may have hit a bug where an implicit copy constructor can't
construct an array of a subtype with a user-defined copy constructor.
I can't see any hits searching for "invalid array assignment" on the
bug repository.
I messed up submitting my last bug so I thought I'd ask here first for
con
On Wed, 24 Nov 2010, Richard Guenther wrote:
> Well. Long term. Hookizing constants is easy - before proceeding
> with those (seemingly expensive) ones I'd like to see all the _hard_
> target macros converted into hooks. If there are only things like
> BITS_PER_UNIT left we can talk again.
I t
On Wed, Nov 24, 2010 at 02:48:01PM +, Pedro Alves wrote:
> On Wednesday 24 November 2010 13:45:40, Joern Rennecke wrote:
> > Quoting Pedro Alves :
> > Also, these separate hooks for common operations can make the code more
> > readable, particularly in the bits_in_units_ceil case.
> > I.e.
> >
Quoting Richard Guenther :
On Wed, Nov 24, 2010 at 3:12 PM, Joern Rennecke wrote:
I'm fine with the RTL optimizers to use target macros, but I'd like the
frontends and tree optimizers to cease to use tm.h . That means
all macros uses there have to be converted. That does not necessarily
invo
On Wed, Nov 24, 2010 at 4:22 PM, Joern Rennecke wrote:
> Quoting Richard Guenther :
>
>> On Wed, Nov 24, 2010 at 3:12 PM, Joern Rennecke
>> wrote:
>>>
>>> I'm fine with the RTL optimizers to use target macros, but I'd like the
>>> frontends and tree optimizers to cease to use tm.h . That means
>
Hi.
This morning's build attempts on both i386-pc-solaris2.10 and
sparc-sun-solaris2.10 failed with the following error:
/export/home/arth/gnu/gcc-1124/./prev-gcc/xgcc
-B/export/home/arth/gnu/gcc-1124/./prev-gcc/
-B/export/home/arth/local/i386-pc-solaris2.10/bin/
-B/export/home/arth/local/i38
On Wed, 24 Nov 2010, Art Haas wrote:
> This morning's build attempts on both i386-pc-solaris2.10 and
> sparc-sun-solaris2.10 failed with the following error:
>
> /export/home/arth/gnu/gcc-1124/./prev-gcc/xgcc
> -B/export/home/arth/gnu/gcc-1124/./prev-gcc/
> -B/export/home/arth/local/i386-pc-sol
Ian Lance Taylor , wrote:
> Tests that directly invoke __builtin functions are not appropriate for
> your replacement for emmintrin.h.
Clearly. However, I do not see why these are in the test routines in
the first place. They seem not to be needed. I made the changes below
my signature, elimin
"David Mathog" writes:
> Ian Lance Taylor , wrote:
>
>> Tests that directly invoke __builtin functions are not appropriate for
>> your replacement for emmintrin.h.
>
> Clearly. However, I do not see why these are in the test routines in
> the first place. They seem not to be needed. I made the
On Wed, Nov 24, 2010 at 4:32 PM, Richard Guenther
wrote:
> On Wed, Nov 24, 2010 at 4:22 PM, Joern Rennecke wrote:
>> Quoting Richard Guenther :
>>
>>> On Wed, Nov 24, 2010 at 3:12 PM, Joern Rennecke
>>> wrote:
I'm fine with the RTL optimizers to use target macros, but I'd like the
Quoting Richard Guenther :
So, Joern, maybe you can clarify what the benefit is in hookizing
BITS_PER_UNIT?
The point is that I want to eliminate all tm.h macro uses from the
tree optimizer and frontend files, so that they can stop including
tm.h . When I first tried putting all patches to el
Ian Lance Taylor wrote:
> Your changes are relying on a gcc extension which was only recently
> added, more recently than those tests were added to the testsuite. Only
> recently did gcc acquire the ability to use [] to access elements in a
> vector.
That isn't what my changes did. The array a
On Nov 24, 2010, at 4:04 PM, Joern Rennecke wrote:
> Quoting Richard Guenther :
>
>> So, Joern, maybe you can clarify what the benefit is in hookizing
>> BITS_PER_UNIT?
>
> The point is that I want to eliminate all tm.h macro uses from the
> tree optimizer and frontend files, so that they can s
Quoting Paul Koning :
If BITS_PER_UNIT is all that's left, could you use some genxxx.c to
extract that from tm.h and drop it into a tm-bits.h in the build
directory? Then you could include that one instead of tm.h.
Yes, that's what I said. Only there is little point in writing
the gener
On Wed, Nov 24, 2010 at 10:04 PM, Joern Rennecke wrote:
> Quoting Richard Guenther :
>
>> So, Joern, maybe you can clarify what the benefit is in hookizing
>> BITS_PER_UNIT?
>
> The point is that I want to eliminate all tm.h macro uses from the
> tree optimizer and frontend files, so that they can
Quoting Richard Guenther :
What's the benefit of not including tm.h in the tree optimizers and frontend
files to our users?
We should see less instability of frontends and tree optimizers for less-often
tested targets. This can prevent release cycles from getting longer, and/or
allow more wor
"David Mathog" writes:
> Ian Lance Taylor wrote:
>
>> Your changes are relying on a gcc extension which was only recently
>> added, more recently than those tests were added to the testsuite. Only
>> recently did gcc acquire the ability to use [] to access elements in a
>> vector.
>
> That isn
On 24/11/2010 14:17, Richard Guenther wrote:
> I don't see why RTL optimizers should be different from tree optimizers.
I thought half the point of tree-ssa in the first place was to separate
optimisation out from target-specific stuff and do it on an independent level?
On 24/11/2010 15:32, Ri
On 24/11/2010 21:31, Joern Rennecke wrote:
> Quoting Paul Koning :
>
>> If BITS_PER_UNIT is all that's left, could you use some genxxx.c to
>> extract that from tm.h and drop it into a tm-bits.h in the build
>> directory? Then you could include that one instead of tm.h.
>
> Yes, that's what I
34 matches
Mail list logo
