On Thu, Oct 1, 2015 at 2:08 AM, Segher Boessenkool <seg...@kernel.crashing.org> wrote: > After the shrink-wrapping patches the prologue will often be pushed > "deeper" into the function, which in turn means the software trace cache > pass will more often want to duplicate the basic block containing the > prologue. This caused failures for 32-bit SVR4 with -msecure-plt PIC. > > This configuration uses the load_toc_v4_PIC_1 instruction, which creates > assembler labels without using the normal machinery for that. If now > the compiler decides to duplicate the insn, it will emit the same label > twice. Boom. > > It isn't so easy to fix this to use labels the compiler knows about (let > alone test that properly). Instead, this patch wires up a "cannot_copy" > attribute to be used by TARGET_CANNOT_COPY_P, and sets that attribute on > these insns we do not want copied. > > Bootstrapped and tested on powerpc64-linux, with the usual configurations > (-m32,-m32/-mpowerpc64,-m64,-m64/-mlra); new testcase fails before, works > after (on 32-bit). > > Is this okay for mainline?
Is this expensive enough that it is worth limiting the definition of the hook to configurations that include 32-bit SVR4 support so that not every configuration incurs the overhead? Thanks, David
