>
> [Peter Samuelson]
> > > One such way is to generate assembler code from its parse trees,
> > > another is through linking to libgcc.a. Thus libgcc.a is in one
> > > sense not really a library so much as just part of the compiler.
> [...]
> > > Why do this work by hand?
> [Alexander Viro]
> > Because in 99% of cases you don't _want_ those operations. Part of
> > standard or not, gcc on x86 makes them _slow_.
>
> So basically we use the absence of libgcc.a as a trap to find compiler
> constructs we consider undesirable. Fair enough, works for me.
Yup. Notice that this set (insn's that went into libgcc) is not random.
And the rationale for their choice is pretty close to "this stuff doesn't
map well on [sucking] target architecture(s)". I.e. the stuff you'ld
better avoid...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/