Joern Rennecke writes:
> Before I go and make all these target changes & test them, is there at
> least agreemwent that this is the right approach, i.e replacing
> CUMULATIVE_ARG *
> with void *, and splitting up x_rtl into two variables.
I don't know how we want to get there, but it seems to me
On Tue, Nov 16, 2010 at 06:23:32AM -0800, Ian Lance Taylor wrote:
> Joern Rennecke writes:
> > Before I go and make all these target changes & test them, is there at
> > least agreemwent that this is the right approach, i.e replacing
> > CUMULATIVE_ARG *
> > with void *, and splitting up x_rtl int
Quoting Nathan Froyd :
On Tue, Nov 16, 2010 at 10:22:00PM -0500, Joern Rennecke wrote:
...
Does that mean you acknowledge that we shouldn't have CUMULATIVE_ARGS
taking hooks in the global target vector?
Maybe? I think the methods discussed in this thread would be better for
when we do move
On Tue, Nov 16, 2010 at 10:22:00PM -0500, Joern Rennecke wrote:
> Quoting Nathan Froyd :
> >I am admittedly a C++ newbie; the first thing I thought of was:
> >
> >class gcc::cumulative_args {
> > virtual void advance (...) = 0;
> > virtual rtx arg (...) = 0;
> > virtual rtx incoming_arg (...) {
Quoting Ian Lance Taylor :
The scheme that Paolo describes avoids virtual functions. But for this
usage I personally would prefer virtual functions, since there is no
efficiency cost compared to a target hook.
Well, actually, there is: you first fetch the object pointer, then you
find the vta
Nathan Froyd writes:
> On Wed, Nov 17, 2010 at 03:40:39AM +0100, Paolo Bonzini wrote:
>> True, but you can hide that cast in a base class. For example you
>> can use a hierarchy
>>
>> Target // abstract base
>> TargetImplBase // provides strong typing
>>
Quoting Nathan Froyd :
I am admittedly a C++ newbie; the first thing I thought of was:
class gcc::cumulative_args {
virtual void advance (...) = 0;
virtual rtx arg (...) = 0;
virtual rtx incoming_arg (...) { return this->arg (...); };
virtual int arg_partial_bytes (...) = 0;
// ...and
On Wed, Nov 17, 2010 at 03:40:39AM +0100, Paolo Bonzini wrote:
> True, but you can hide that cast in a base class. For example you
> can use a hierarchy
>
> Target // abstract base
> TargetImplBase // provides strong typing
> TargetI386
On 11/17/2010 03:10 AM, Ian Lance Taylor wrote:
Joern Rennecke writes:
I don't see how going to a struct cumulative_args gets us closer
to a viable solution for a multi-target executable, even if you
threw in C++. Having the target describe a type, and shoe-horning
this through a target hook i
Joern Rennecke writes:
> I don't see how going to a struct cumulative_args gets us closer to
> a viable solution for a multi-target executable, even if you threw in
> C++. Having the target describe a type, and shoe-horning this through
> a target
> hook interface that is decribed in supposedly
Quoting Paolo Bonzini :
I think a multi-target executable would be just too ugly in C due to
issues such as this. I don't think it's worthwhile to sacrifice type
safety now, so a struct cumulative_args is preferrable.
I don't see how going to a struct cumulative_args gets us closer to
a viabl
On 11/16/2010 10:17 PM, Ian Lance Taylor wrote:
I don't know how we want to get there, but it seems to me that the place
we want to end up is with the target hooks defined to take an argument
of type struct cumulative_args * (or a better name if we can think of
one).
Actually, this doesn't work
Joern Rennecke writes:
> Quoting Ian Lance Taylor :
>
>> Joern Rennecke writes:
>>
>>> Before I go and make all these target changes & test them, is there at
>>> least agreemwent that this is the right approach, i.e replacing
>>> CUMULATIVE_ARG *
>>> with void *, and splitting up x_rtl into two
Quoting Ian Lance Taylor :
Joern Rennecke writes:
Before I go and make all these target changes & test them, is there at
least agreemwent that this is the right approach, i.e replacing
CUMULATIVE_ARG *
with void *, and splitting up x_rtl into two variables.
I don't know how we want to get t
Quoting Ian Lance Taylor :
Joern Rennecke writes:
Before I go and make all these target changes & test them, is there at
least agreemwent that this is the right approach, i.e replacing
CUMULATIVE_ARG *
with void *, and splitting up x_rtl into two variables.
I don't know how we want to get t
Quoting Ian Lance Taylor :
Joern Rennecke writes:
Before I go and make all these target changes & test them, is there at
least agreemwent that this is the right approach, i.e replacing
CUMULATIVE_ARG *
with void *, and splitting up x_rtl into two variables.
I don't know how we want to get t
target.h and function.h include tm.h, and they got data structure dependencies
that are painful to untangle. function.h requires x_rtl to be split into
a target-type tainted part and one that can be used in tree optimizers
/ frontends
(via the inline functions in emit-rtl.c). To get rid of t
Quoting Paolo Bonzini :
Augmenting libcpp with a new kind of poisoning that only affect
preprocessor conditionals would probably make this a lot simpler.
If we don't have a wrapper macro, we can just poison the macro.
I still have to find out how practical that is, but for now let's assume
we
On 11/15/2010 04:48 PM, Joseph S. Myers wrote:
* The macro is tested with #if/#ifdef/#ifndef/#elif in a source file
outside of config/ (but including front-end subdirectories). Care is
needed in identifying such macros through grep because of
backslash-newline line continuations and because it's
On Mon, 15 Nov 2010, Joern Rennecke wrote:
> Quoting "Joseph S. Myers" :
>
> > On Mon, 15 Nov 2010, Joern Rennecke wrote:
> >
> > > With 638 macros documented by @defmac, and 475 files that include tm.h ,
> > > our current approach to hookization is too slow to get the tree optimizers
> > > and
Quoting "Joseph S. Myers" :
On Mon, 15 Nov 2010, Joern Rennecke wrote:
With 638 macros documented by @defmac, and 475 files that include tm.h ,
our current approach to hookization is too slow to get the tree optimizers
and front ends independent of target macros in any useful timeframe.
I th
On Mon, 15 Nov 2010, Joern Rennecke wrote:
> With 638 macros documented by @defmac, and 475 files that include tm.h ,
> our current approach to hookization is too slow to get the tree optimizers
> and front ends independent of target macros in any useful timeframe.
I think it's perfectly feasible
With 638 macros documented by @defmac, and 475 files that include tm.h ,
our current approach to hookization is too slow to get the tree optimizers
and front ends independent of target macros in any useful timeframe.
Therefore, I propose the following approach:
The target macros currently require
23 matches
Mail list logo
