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
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 cause
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
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 par
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 coul
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 instr
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/
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 a
