[llvm-commits] move CPU detection from lib/Target/$FOO to libSystem

Chandler Carruth chandlerc at google.com
Sat Nov 14 01:46:21 PST 2009


On Sat, Nov 14, 2009 at 1:13 AM, Roman Divacky <rdivacky at freebsd.org> wrote:
> On Fri, Nov 13, 2009 at 10:18:31PM -0800, Chandler Carruth wrote:
>> On Fri, Nov 13, 2009 at 3:48 AM, Roman Divacky <rdivacky at freebsd.org> wrote:
>> > hi
>> >
>> > the attached patch moves cpu detection code from lib/Target/$FOO
>> > (for FOO=X86 :) ) to lib/System. This is necessary for clang
>> > to be able to do -march=native. The patch was already reviewed
>> > by Daniel Dunbar.
>> >
>> > Can you please review/commit this?
>>
>> A meta-point: you're moving a lot more than just GetCurrentX86CPU into
>> libSystem, can you expose the other functions and delete the copies in
>> X86Subtarget? I'd rather avoid duplicating subtle code like that.
>
> I was told to not expose any target specific functionality, the
> GetX86CpuIDAndInfo and DetectX86FamilyModel are fairly small and not
> likely to change often. I dont like the duplication either butcant think of
> any way to reach this X86 specific stuff from libSystem.

I was thinking the other way around: expose this in libSystem so that
the X86 target can leverage it. I agree libSystem shouldn't depend on
libTarget.

That said, I don't have a clean API for it at first glance -- I
suspect each target has its own target-specific routines it needs
access to -- but if these are useful for the host as well as the
target, it makes sense to me for them to live in libSystem rather than
a target library. Maybe others have ideas on how best to organize such
helper routines?

>
>> Also, why add the include on StringMap?
>
> oh.. leftover from previous attempts :)
>
> new patch attached
>
> thnx for review!
>



More information about the llvm-commits mailing list