[rth, see below]
local_define_builtin ("__builtin_eh_pointer", ftype, BUILT_IN_EH_POINTER,
"__builtin_eh_pointer", ECF_PURE | ECF_NOTHROW |
ECF_LEAF);
+ if (flag_tm)
+ apply_tm_attr (builtin_decl_explicit (BUILT_IN_EH_POINTER),
+ get_identifier ("transaction_pure"));
I think this should use a new ECF_TM_PURE flag, unconditionally set
with handling in the functions that handle/return ECF flags so that
transitioning this to a tree node flag instead of an attribute is easier.
I could add a ECF_TM_PURE flag and attach it to the BUILT_IN_EH_POINTER
in the local_define_builtin above, but we still need the attribute for
function decl's as in:
__attribute__((transaction_pure)) void foo();
Attributes seem like a clean way to approach this.
I don't see what the flag buys us. Or am I misunderstanding something?
+/* Nonzero if this call performs a transactional memory operation. */
+#define ECF_TM_OPS (1<< 11)
What's this flag useful for? Isn't it the case that you want to conservatively
know whether a call might perform a tm operation? Thus, the flag
should be inverted? Is this the same as "TM pure"?
Richard?
+ case GIMPLE_TRANSACTION:
+ return (weights->tm_cost
+ + estimate_num_insns_seq (gimple_transaction_body (stmt),
+ weights));
+
Huh, so we now have non-lowered gimple sub-sequence throughout all
optimizations (inlining especially)? :(
Richard addressed this elsewhere.
I think I miss tree-cfg.c parts that do any verification of the new gimple
kinds.
Yes, they're there. I see you commented on them in the middle/end
patch. I will fix the issues you brought up on that thread.
? Why not use GF_CALL_CANNOT_INLINE?
As per Michael Matz's suggestion, I have removed all reference to this
unused flag.
+static inline void
+gimple_call_set_noinline_p (gimple s)
+{
+ GIMPLE_CHECK (s, GIMPLE_CALL);
+ s->gsbase.subcode |= GF_CALL_NOINLINE;
+}
See above. We have *_cannot_inline already.
Similarly here.
Richi, I have fixed or addressed all the issues in this thread, with the
exception of your EFC_TM_PURE and ECF_TM_OPS questions, which I am
deferring to rth and then fixing if required. I will now go through the
middle-end thread (which erroneously also prefixed with [patch] 19/n...).
Aldy
