[cfe-commits] r56293 - /cfe/trunk/lib/CodeGen/CGCall.cpp

[Daniel Dunbar]

Yes, its not really clear how it should be organized. I'd rather not
continue to build up the code in CodeGen, it would be much nicer to be
separated by target. However, its true that leaving it in CodeGen can
be made to work with minimal impact; and it does have the benefit of
not splitting stuff apart before its clear the API will work.

I talked with Chris a little about this yesterday and he was fine with
ignoring the problem that the targets live below the AST for now. How
would you feel about moving all the target stuff into its own
directory? For the time being it would be allowed to depend on AST
(i.e. use Types). In the future if/when we want to be able to build a
preprocessor without linking in other code we can decide the best way
to split the Targets apart to support this.

 - Daniel

On Wed, Sep 17, 2008 at 4:47 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Wed, Sep 17, 2008 at 2:22 PM, Daniel Dunbar <daniel at zuster.org> wrote:
>>  - Upcoming: Figure out how to refactor ABI handling into
>>   targets.
>
> I've actually thought about this a bit.  We can't really put the ABI
> handling into the targets easily; the targets are in Basic, and
> therefore aren't allowed to know about the type system.  I think the
> most straightforward thing to do is to add a "CallGenStyle" flag to
> the TargetInfo (so X86 would have the "X86" call style, X86-64 would
> have the "X86-64" call style, etc.).  Then, the actual ABI code ends
> up in CodeGen.  This way, we get the most flexibility for the initial
> implementation.
>
> The downside of this approach, of course, is that adding a new target
> will involve modifying CodeGen; however, I don't it's a good idea to
> try to abstract out the rules before we have implementations for a few
> distinct targets.
>
> -Eli
>