On 11/23/2010 12: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 operations.
> So ma
On Nov 24, 2010, at 9:37 PM, Dave Korn wrote:
> On 24/11/2010 21:31, Joern Rennecke wrote:
>> ...
>> We can add the generator program when we (re-) add a word addressed
>> target, or add a bit addressed one.
>
> I do think that this goal is not so far off that we should actually
> encourage new
On Thu, Nov 25, 2010 at 3:32 AM, Dave Korn wrote:
> 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
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
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
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
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 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 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 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
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
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
>
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 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.
> >
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 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
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 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: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: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
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 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 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 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
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 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
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
Quoting "Joseph S. Myers" :
If something relates to an interface to a lower-level part of the compiler
then BITS_PER_UNIT is probably right - but if somethis relates to whether
a type is a variant of char, or to alignment of a non-bit-field object
(you can't have smaller than char alignment), or
I think quite a lot of front end uses of BITS_PER_UNIT should really be
TYPE_PRECISION (char_type_node) (which in general I'd consider preferred
to CHAR_TYPE_SIZE in the front ends). Though it's pretty poorly defined
what datastructures should look like if target "char" in the front ends is
wi
29 matches
Mail list logo
