[Bug target/52323] i386: gcse runs amok with pic-addresses

["kaffeemonster at googlemail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52323

--- Comment #3 from Jan Seiffert <kaffeemonster at googlemail dot com> 2012-02-22 00:03:53 UTC ---
My use case are not large floating point math funcs.

While intrinsics are nice (the new Tile ports rock! Every spec. instruction as
intrinsic from day 1, that's how it should be for a VLIW arch, can't say the
same for IA64...), for x86 they are generally not on my radar.
x86 being the primary architecture today for my use case, if things are only
mediocre on PPC/ARM or whatever, i can live with it, but not for x86.
And on x86 intrinsics simply do not work good enough.

Intrinsics have one "deadly" limitation:
You can only use them if -march= is set right.
And x86 has one gazillion ISA extensions, every 2 years a new one.
This way you can not wright code which dynamically dispatches at runtime.
User which get code by some general build (Distro, package from website) are
the majority for x86. You can expect from an PPC user or ARM user or Alpha user
to set his march right, he will be compiling it by himself anyway, but not for
x86. Also distros "hate it" when you do not obey the CFLAGS they set during
build and muck around with these CFLAGS (for good reasons).

BMI2 is an ISA extention where the CPUs will only get released. If there are
intrinsics in GCC for it, it's prop. somewhere in CVS. GCCs in use out there
are generally not bleeding edge new.

Another problem is what GCC (but also other compiler) does when he is "one or
two" register short (very common on i386). Stackframe, foo, bar, often not the
perfect spill (to but it in a positive light). This is the point where a human
can either: a) find a better spill (more cold) b) squeeze and push and shove to
make it fit. But you can't flip a switch on a compiler: "please be 20% smarter
now".

And so why write it as inline asm instead of a stand alone .s? Let the compiler
do the leg work, that's his job. Calling conventions, debug info, sections,
.gnu-note-stack, pic/non-pic, etc. I only need to write the kernel and can do
as much or few as i like to, without wasting any thought on the ASM boiler
plate stuff.

I could write it with intrinsics for this testcase (but then the problem would
prop. vanish?), i generally do not for x86 and this is a snipped from a larger
code body. (the alpha version uses __builtin_zapnot and __builtin_cmpbge, the
NEON version uses the stuff from neon.h, but for other instruction sets, there
are not enough intrinsics or they work poorly (ex. ARM iWMMXt, MIPS
Loongson)...)