This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Can we speed up the gcc_target structure?

"Zack Weinberg" <> writes:

> Of course inefficiencies are going to be introduced if we just convert
> each macro to a target hook with the same semantics.  But that isn't
> the only option on the table.  The right thing is to redesign this
> interface so that it doesn't *need* 100+ macros and toggles.  If this
> is done properly, then not only should there be no inefficiency
> introduced by going through the target vector, but also we would have
> something that was straightforward to maintain and straightforward to
> add support for new architectures.
> As a data point, I am aware of another (proprietary) compiler that
> completely isolates the back end from the optimizers, to the point
> where the back end module can be swapped out at runtime, and it
> benchmarks competitively or faster than GCC on similar input.  So I
> don't believe that this is impossible.

Sounds good.  I think most people would agree that gcc has always
brought details of the target too far forward in the compilation
process.  But it's a pretty substantial project, given the current
code base.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]