Am 17.08.2012 19:57, schrieb Jorge Almeida:
> On Fri, Aug 17, 2012 at 2:53 PM, Florian Philipp <li...@binarywings.net> 
> 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?
>>>
>>> TIA
>>>
>>> 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
>> l2-cache-size=512".
>>
>> 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 :
> atom
> 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.
> 
> Thanks
> 
> 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.

Regards,
Florian Philipp

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to