On Tue, Mar 27, 2012 at 6:57 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>> Well, generally speaking, reload makes a lot of assumptions on how >>> addresses can look like; it needs to, since if a target rejects an >>> address as invalid as-is, reload must fix it up -- and it can do >>> so only by making assumptions ... >>> >>> Allowing a random UNSPEC as part of valid (non-strict) addresses >>> makes it really impossible for reload to understand what's going >>> on. Given that, I'd tend to agree that *if* you do that, you >>> then also have to help reload how to deal with such addresses >>> by providing a legitimize_reload_address hook as you did. >>> >>> Now, in this particular case, there might be another option to >>> avoid this hassle completely: I understand that this UNSPEC is >>> simply a magic marker to make the address use the fs: or gs: >>> segment override, right? Now that GCC supports address spaces, >>> it might be possible to model fs:/gs: relative addresses instead >>> by using a non-standard address space ... >> >> This is an interesting idea, I will look into it. > > As I explained in: > > http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01590.html > > we can remove *load_tp_x32_zext and use > > (define_insn "*load_tp_x32_<mode>" > [(set (match_operand:SWI48x 0 "register_operand" "=r") > (unspec:SWI48x [(const_int 0)] UNSPEC_TP))] > "TARGET_X32" > "mov{l}\t{%%fs:0, %k0|%k0, DWORD PTR fs:0}" > [(set_attr "type" "imov") > (set_attr "modrm" "0") > (set_attr "length" "7") > (set_attr "memory" "load") > (set_attr "imm_disp" "false")]) > > to load %fs directly into %r32 or %r64. No, we can't. Uros.
