Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

2015-01-14 Thread Markus Meier
On Wed, 14 Jan 2015 12:58:21 +0100
Michał Górny  wrote:

> Solution: per-arch USE_EXPANDs for flags, e.g.:
> 
>   CPU_FLAGS_X86="3dnow 3dnowext avx ..."
>   CPU_FLAGS_ARM="neon ..." # arm* flags?
>   CPU_FLAGS_MIPS="..." # mips* flags?
> 
> Any specific comments? I can handle x86 but I'd appreciate specific
> arch teams replying about more exotic arches.

+1

For arm we will likely need the following flags (from arm and armv7a
profiles use.mask):
iwmmxt
neon
armvfp
armv5te
armv6
armv6t2


Regards,
Markus


signature.asc
Description: PGP signature


Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

2015-01-14 Thread Andreas K. Huettel
Am Mittwoch, 14. Januar 2015, 12:58:21 schrieb Michał Górny:
> 
> Solution: per-arch USE_EXPANDs for flags, e.g.:
> 
>   CPU_FLAGS_X86="3dnow 3dnowext avx ..."
>   CPU_FLAGS_ARM="neon ..." # arm* flags?
>   CPU_FLAGS_MIPS="..." # mips* flags?
> 

I like it, because it standardizes and removes causes for confusion. So, +1.

That said, long time ago I was taught that "instruction set use-flags" should 
be avoided as much as possible. I don't remember the source for that anymore. 

Question to all, is that documented anywhere, and what are the specifics?
I suspect "use flags that only switch CFLAGS etc" are forbidden, "useflags 
that enable assembler code etc" are allowed?

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/



signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

2015-01-14 Thread Zac Medico
On 01/14/2015 09:55 AM, Christopher Head wrote:
> On January 14, 2015 7:16:46 AM PST, Alexis Ballier  
> wrote:
>> however, i disagree with your rationale: asm for specific cpu
>> extensions tend to be written and tested after given cpu is available,
>> thus if you have a brand new cpu, you want to be notified if a package
>> gains support for this new instruction set
> 
> Do people really want to be notified if a package gains support for a new 
> instruction set? I know I don’t. 

Don't worry. You'll only be "notified" in the sense that you can see the
new flags highlighted in the emerge --verbose output.

> I would rather have all possible instruction set extensions available as 
> flags and set whichever ones my CPU has once, at install time. If a package 
> gains support for an extension later, then whenever it upgrades, it will just 
> work, because the relevant flag will already be set in make.conf from back 
> when I installed Gentoo on the box.

Yes, that's how it will work. You just set your flags, or the profile
does it for you, and you're done.

> For this to work right requires that a dev add all the extensions to the flag 
> before I buy the CPU. All that requires is knowing the names, though; it 
> would be fine if no package actually uses the feature yet.

Why should we have to foresee the future? We can easily add support for
new flags in CPU_FLAGS_* variables at any time.
-- 
Thanks,
Zac



Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

2015-01-14 Thread Zac Medico
On 01/14/2015 10:28 AM, Anthony G. Basile wrote:
> Would this approach clean up some of the masking?  Eg. I hate having to
> mask sse and friends in base/use.mask and then unmask them in
> arch/amd64/use.mask.  I'm not sure if there's a technique to make a use
> expand flags relevant only for a particular profile.

The USE_EXPAND flags are essentially the same a regular USE flags. The
"special technique" for masking USE_EXPAND flags would be to mask flags
like cpu_flags_neon as though they are regular USE flags.
-- 
Thanks,
Zac



Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

2015-01-14 Thread Anthony G. Basile

On 01/14/15 10:16, Alexis Ballier wrote:

On Wed, 14 Jan 2015 12:58:21 +0100
Michał Górny  wrote:


Any specific comments? I can handle x86 but I'd appreciate specific
arch teams replying about more exotic arches.

+1

i like the idea, but with a list of useflags that would get converted
this could "reach" more people i think


This sounds good to me too.  Expansions to the base instruction set 
architecture is something more pertinent to the intel family going back 
to the pentium II days with mmx afaik and multiplying like rabbits every 
since.  There is neon for arm and I don't know of any for mips or ppc.


Would this approach clean up some of the masking?  Eg. I hate having to 
mask sse and friends in base/use.mask and then unmask them in 
arch/amd64/use.mask.  I'm not sure if there's a technique to make a use 
expand flags relevant only for a particular profile.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA




Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

2015-01-14 Thread Christopher Head
On January 14, 2015 7:16:46 AM PST, Alexis Ballier  wrote:
>however, i disagree with your rationale: asm for specific cpu
>extensions tend to be written and tested after given cpu is available,
>thus if you have a brand new cpu, you want to be notified if a package
>gains support for this new instruction set

Do people really want to be notified if a package gains support for a new 
instruction set? I know I don’t. I would rather have all possible instruction 
set extensions available as flags and set whichever ones my CPU has once, at 
install time. If a package gains support for an extension later, then whenever 
it upgrades, it will just work, because the relevant flag will already be set 
in make.conf from back when I installed Gentoo on the box.

For this to work right requires that a dev add all the extensions to the flag 
before I buy the CPU. All that requires is knowing the names, though; it would 
be fine if no package actually uses the feature yet.

-- 
Christopher Head



Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

2015-01-14 Thread Alexis Ballier
On Wed, 14 Jan 2015 12:58:21 +0100
Michał Górny  wrote:

> Any specific comments? I can handle x86 but I'd appreciate specific
> arch teams replying about more exotic arches.

+1

i like the idea, but with a list of useflags that would get converted
this could "reach" more people i think

profiles/base/use.mask should be organized enough to easily get such a
list

however, i disagree with your rationale: asm for specific cpu
extensions tend to be written and tested after given cpu is available,
thus if you have a brand new cpu, you want to be notified if a package
gains support for this new instruction set

the advantages I see is that for packages like mplayer or ffmpeg, it
is a pain to distinguish what is a cpu extension, what is a codec or
what is just a preference over an external lib; this would make it
clear.

USE_EXPAND_HIDDEN would also make irrelevant flags for your
architecture hidden and not just masked.


Alexis.



[gentoo-dev] Moving CPU flags into USE_EXPAND

2015-01-14 Thread Michał Górny
Hi,

I think this has been discussed already [1] but in the end never was
applied or even finished discussing. So I'd like to revive the topic
and apply the necessary changes in a few days if nobody objects
strongly.

Rationale: we have a growing number of CPU-corresponding flags that all
are fit as global USE flags by definition and are usually set once
by user. As far as I'm aware, CPUs don't grow new instruction sets once
installed, so in most of the cases user doesn't need to be concerned by
additional cryptic flag names once he set up his CPU.

Solution: per-arch USE_EXPANDs for flags, e.g.:

  CPU_FLAGS_X86="3dnow 3dnowext avx ..."
  CPU_FLAGS_ARM="neon ..." # arm* flags?
  CPU_FLAGS_MIPS="..." # mips* flags?

Any specific comments? I can handle x86 but I'd appreciate specific
arch teams replying about more exotic arches.

[1]:http://thread.gmane.org/gmane.linux.gentoo.devel/69141

-- 
Best regards,
Michał Górny


pgpvXfbEL7jx4.pgp
Description: OpenPGP digital signature