This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, updated] Make emulated TLS lto-friendly.


On Tue, Jul 13, 2010 at 11:48 PM, Richard Henderson <rth@redhat.com> wrote:
> On 07/13/2010 02:39 PM, Andrew Pinski wrote:
>> On Tue, Jul 13, 2010 at 2:19 PM, Richard Henderson <rth@redhat.com> wrote:
>>>
>>> That change, however, alters the valid arguments to MEM_REF. ?In that
>>> &tlsvar is no longer valid. ?Now, one could spend forever slightly
>>> tweeking all of the myriad predicates involved, but what it comes down
>>> to is that forwprop does not have the same checks that verify_expr does.
>>
>> Hmm, this sounds like
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824 where there are
>> problems with ADDR_EXPR being inside MEM_REF in some other cases.
>
> Yes, that's exactly the same problem: DLLIMPORT_P variables are
> also !is_gimple_min_invariant, via !decl_address_invariant_p.

Hm, I'll look at that PR (though the DLLIMPORT_P exclusion is odd).

> (Although for the life of me I can't tell you why -- the expansion
> to *__imp_foo doesn't happen until rtl expansion time, and the value
> is in fact function invariant (initialized at load time, like .got).
> I tried to do a bit of spelunking to figure out the change history,
> but svn blame -rN doesn't seem to work with files that are no longer
> present at HEAD.)

Well.  Are there any VAR_DECLs whose addresses are not function
invariant?

As for DLLIMPORT_P I'd suggest simply making it so and watching for
the fallout.

Richard.

>
> r~
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]