[rth, please correct me if I have misrepresented the TM semantics and
rules].
On 02/15/12 09:04, Richard Guenther wrote:
Ok, I had a look at the bugreport and am curios why
__attribute__((always_inline))
static void asmfunc(void)
{
__asm__ ("");
}
__attribute__((transaction_safe))
static void f(void)
{
asmfunc();
}
you'd want a diagnostic when asmfunc is not inlined but OTOH do not
want to ICE when it is. Why not diagnose GIMPLE_ASMs alongside
other 'unsafe function calls'. Thus, why does __attribute__((transaction_safe))
not transitively cover all its callees (does it?)?
No, transaction_safe does not transitively cover its callees. A
transaction safe function cannot call unsafe functions, nor can
GIMPLE_ASMs appear in it.
(This was confusing for me at first too, because transaction_pure OTOH,
does allow any type of call inside, or GIMPLE_ASM. For
transaction_pure, no instrumentation is done, and the function is
outputted as is.)
The comment of ipa_tm_diagnose_tm_safe says
/* Diagnose calls from transaction_safe functions to unmarked
functions that are determined to not be safe. */
and this "determined to not be safe" is what I was refering to with pointing
to how we handle pure/const "discovery".
Interesting. I suppose we can add a cgraph bit for "this function may
go irrevocable" and accumulate it during pure/const discovery.
For the asm above - how do you discover an asm is "unsafe"? I suppose
you cannot, and you only consider asms lexically in a function marked
as transaction-safe as safe? If so might I suggest to use a flag on the
GIMPLE_ASM stmt, set during initial tm lowering (or even during parsing maybe)?
No, AFAIK, asms aren't safe even in transaction_safe functions (don't
look at me, I didn't write the standard). But rth can correct me if I'm
wrong.
So as you compute/propagate the tm_may_enter_irr flag only during
IPA TM you might do better (with deciding what to allow to inline during
early inlining, or other stuff) if you compute this function local property
(conservatively) late in the early optimization pipeline, close to
pass_local_pure_const (or simply integrated within it) - benefiting from
trivial propagation ensured by the way we walk functions in the callgraph
during early optimizations. The IPA TM pass then simply would do the
propagation of the flag (no need to scan function bodies here, so this can
even work at LTO level!)
Nice. I like it. I will play around with it.
Hope that helps ;)
Definitely, thanks!
Aldy
