lists at binarywings
Aug 17, 2012, 2:05 PM
Post #4 of 6
Am 17.08.2012 19:57, schrieb Jorge Almeida:
> On Fri, Aug 17, 2012 at 2:53 PM, Florian Philipp <lists [at] binarywings> wrote:
>> Am 17.08.2012 10:58, schrieb Jorge Almeida:
>>> 1) Is this strategy right? If so, any other flags to add? (or any
>>> flags to remove from the list?)
>>> 2) The --param flags are the ones of the computer that will do the
>>> compiling. I'm guessing the produced binaries are compatible with cpu
>>> with different --param flags. Is this right?
>>> Jorge Almeida
>> 1) Yes. But as you can see, -march=prescott is basically a subset of
>> atom. In fact, before there was a -march=atom option, prescott was the
>> best flag for atoms. I think you can avoid some hassle by simply
>> enabling "-march=prescott --param l1-cache-line-size=64 --param
>> 2) Yes, the param flags do not affect compatibility. Using the lower
>> value will probably be better but this is just an educated guess.
> What about:
> CFLAGS="-O2 -pipe -fomit-frame-pointer -march=prescott -mtune=atom --param
> l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=1024"
> If prescott were exactly a subset of atom, this would yield the best of both
> worlds. Can it still be safe?
> I read in http://forums.gentoo.org/viewtopic-t-895104.html :
> Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3
> instruction set support.
> Does this mean that these flags are pulled by -mtune=atom, or do we need to
> ask for them explicitly? The WiKi shows how to find which flags are pulled by
> -march=native, but not the other cases.
> Jorge Almeida
Oh, sorry, I didn't think of the second generation atoms. I guess your
newer atom is a bit more different from prescott than the one I talked
about. Anyway, using -march=prescott is still viable. It just means you
lose a bit more in terms of usable SSE extensions on your atom.
Your CFLAGS look good to me. They won't pull in anything that your
prescott cannot handle.