In theory we should be able to do multiple "LTO" passes. So we could do
a.c a.o
... -> -> WPA -> LTRANS and TM lowering -> WPA -> LTRANS and RTL
expand
x.c x.o
Thus, after a first wave of WPA and LTRANS in non-lowered TM we can,
after the TM lowering in the first LTR
>
> I'm not sure TM people care about double streaming cost ;) As far as I can
> see TM people want the non-lowered form go through at least loop
> optimizations,
> so I don't see how even a proper IPA pass would help here. As of
> cherry-picking
:) Yep, this is kind of similar to what we may
On Tue, Jun 26, 2012 at 10:29 AM, Jan Hubicka wrote:
>> On Mon, Jun 25, 2012 at 4:32 PM, Richard Henderson wrote:
>> > On 2012-06-22 06:08, Richard Guenther wrote:
>> >> Do I understand correctly that inlining the builtin at expansion time is
>> >> not
>> >> good because the implementation detai
> On Mon, Jun 25, 2012 at 4:32 PM, Richard Henderson wrote:
> > On 2012-06-22 06:08, Richard Guenther wrote:
> >> Do I understand correctly that inlining the builtin at expansion time is
> >> not
> >> good because the implementation detail may depend on how libitm was
> >> configured?
> >
> > Mor
On Mon, Jun 25, 2012 at 4:32 PM, Richard Henderson wrote:
> On 2012-06-22 06:08, Richard Guenther wrote:
>> Do I understand correctly that inlining the builtin at expansion time is not
>> good because the implementation detail may depend on how libitm was
>> configured?
>
> More or less, yes.
>
>
>
a) If a user provides a builtin implementation to LTO, it is discarded,
since by design LTO prefers builtins to user-provided versions of them. In
LTO, builtins are their own prevailing decl. There is an enhancement
request PR here:
http://gcc.gnu.org/bugzi
a) If a user provides a builtin implementation to LTO, it is discarded,
since by design LTO prefers builtins to user-provided versions of them. In
LTO, builtins are their own prevailing decl. There is an enhancement
request PR here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51997
On 2012-06-22 06:08, Richard Guenther wrote:
> Do I understand correctly that inlining the builtin at expansion time is not
> good because the implementation detail may depend on how libitm was
> configured?
More or less, yes.
We want tm in gcc to be useful to researchers experimenting in the are
> On Fri, Jun 22, 2012 at 2:47 PM, Aldy Hernandez wrote:
> > Hi gentlemen.
> >
> > I am looking again at LTO + TM. The goal is to be able to link with the
> > implemented _ITM_* functions in libitm.a, and have them inlined into the
> > transaction code when profitable.
> >
> > To refresh everyone
On Fri, Jun 22, 2012 at 2:47 PM, Aldy Hernandez wrote:
> Hi gentlemen.
>
> I am looking again at LTO + TM. The goal is to be able to link with the
> implemented _ITM_* functions in libitm.a, and have them inlined into the
> transaction code when profitable.
>
> To refresh everyone's memory, the o
Hi gentlemen.
I am looking again at LTO + TM. The goal is to be able to link with the
implemented _ITM_* functions in libitm.a, and have them inlined into the
transaction code when profitable.
To refresh everyone's memory, the original problem was two-fold:
a) If a user provides a builtin i
11 matches
Mail list logo
