On 05/19/2015 11:06 AM, Rich Felker wrote: > I'm still mildly worried that concerns for supporting > relaxation might lead to decisions not to optimize code in ways that > would be difficult to relax (e.g. certain types of address load > reordering or hoisting) but I don't understand GCC internals > sufficiently to know if this concern is warranted or not.
It is. The relaxation that HJ is working on requires that the reads from the got not be hoisted. I'm not especially convinced that what he's working on is a win. With LTO, the compiler can do the same job that he's attempting in the linker, without an extra nop. Without LTO, leaving it to the linker means that you can't hoist the load and hide the memory latency. > I would still like to see the @GOTPCREL stuff added and used instead > of @GOT, as I mentioned earlier in the thread, but I agree that's > independent of relaxation support and shouldn't block it. I don't think that @GOTPCREL for 32-bit is a good idea. This is the scheme that Darwin uses, so we do have some experience with it. In order for it to work you've got to have a pointer to a random address in the function. It means that you can only "easily" compute the address once. If you need the value again you wind up with the same "extra" addl insn that we have with the current GOT pointer. We've just started to do inter-function register allocation. The next step along those lines is to share the computation of GOT between multiple functions. At which point it really helps to have one global base address to talk about. r~
