Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]
On Tue, Apr 26, 2016 at 03:24:48PM +0930, Alan Modra wrote: > On Mon, Apr 25, 2016 at 11:35:46AM -0600, Jeff Law wrote: > > No, we revert to the gcc-4.9 behavior WRT protected visibility and ensure > > that we're getting a proper diagnostic from the linker. > > > > That direction is consistent with the intent of protected visibility, fixes > > the problem with preemption of protected symbols and gives us a diagnostic > > for the case that can't be reasonably handled. > > I agree that this is the correct solution. Unfortunately there is a > complication. PIE + shared lib using protected visibility worked fine > with gcc-4.9, but since then code generated by gcc for PIEs on x86_64 > has been optimized to rely on the horrible old hack of .dynbss and > copy relocations. That means you'll have regressions from 4.9 if just > reverting the protected visibility change.. > > The PIE optimization will need reverting too, and I imagine you'll see > some resistance to that idea due to the fact that it delivers quite a > nice performance improvement for PIEs. Yes, that change is IMHO too important to revert, it basically made PIEs usable without significant slowdown. Regressing on protected visibility is fine, that is something that is only rarely used and in an ideal world wouldn't be used at all, because the current definition really is not an optimization. If we want to use protected for something, it should be declared that address comparisons are undefined for them, and for references to protected variables from binaries (PIEs or normal) or perhaps even other shared libraries (other than the one with definition) we should just require some extra attribute on them to make this clear and force using GOT there. Jakub
Re: Question on TARGET_MMX and X86_TUNE_GENERAL_REGS_SSE_SPILL
2016-04-14 8:39 GMT+03:00 Kumar, Venkataramanan :
> Hi,
>
> X86_TUNE_GENERAL_REGS_SSE_SPILL: Try to spill general regs to SSE regs
> instead of memory.
>
> I tried enabling the above tuning with -march=bdver4 -Ofast
> -mtune-ctrl=general_regs_sse_spill.
> I did not find any code differences.
>
> Looking at the below code to enable this tune, mmx ISA needs to be turned
> off.
>
> static reg_class_t
> ix86_spill_class (reg_class_t rclass, machine_mode mode)
> {
> if (TARGET_SSE && TARGET_GENERAL_REGS_SSE_SPILL && ! TARGET_MMX
> && (mode == SImode || (TARGET_64BIT && mode == DImode))
> && rclass != NO_REGS && INTEGER_CLASS_P (rclass))
> return ALL_SSE_REGS;
> return NO_REGS;
> }
>
> All processor variants enable MMX by default and why we need to switch off
> mmx?
That really looks weird to me. I ran SPEC2006 on Ofast + LTO with and
without -mno-mmx and
-mno-mmx gives (Haswell machine):
SPEC2006INT :+0.30%
SPEC2006FP :+0.60%
SPEC2006ALL :+0.48%
Which is quite surprising for disabling a hardware feature hardly used
anywhere now.
Thanks,
Ilya
>
> Thanks and regards,
> Venkat.
gcc-5-20160426 is now available
Snapshot gcc-5-20160426 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160426/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 235456 You'll find: gcc-5-20160426.tar.bz2 Complete GCC MD5=77a9120630dab28328889514618f3be3 SHA1=e52feb330bb42b5ce4358eea416e9002f09966f9 Diffs from 5-20160419 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
