On Tue, Mar 27, 2012 at 9:37 AM, Uros Bizjak <ubiz...@gmail.com> wrote: > On Tue, Mar 27, 2012 at 6:13 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote: > >>> Since fixing reload issues is some kind of black magic, I'd like to >>> ask Ulrich and Richard for their opinion on this approach. >> >> 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. -- H.J.
