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

Roman Divacky rdivacky at freebsd.org
Sat Nov 14 01:48:14 PST 2009


On Sat, Nov 14, 2009 at 01:46:21AM -0800, Chandler Carruth wrote:
> 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.
 
I know... I already did it like this but daniel preferred this way. I have
to agree that this looks better

> 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?

I have no idea.... 



More information about the llvm-commits mailing list