On Mon, Feb 27, 2012 at 5:44 PM, Andrew MacLeod <amacl...@redhat.com> wrote: > On 02/27/2012 11:22 AM, Aldy Hernandez wrote: >> >> >>> Ok. I see. So, I think what would be best is to have a way to check >>> whether >>> a store/load is part of a transaction - do we have a way to do that right >>> now? >>> (For example a flag on a gimple stmt?) Then we can simply avoid the LIM >> >> >> We do not (*). My patch accumulates that information on demand. I can >> certainly add a gimple bit for this, but can't the optimizations >> change/rewrite the stores/loads so we lose this information?
Yes, we'd have to either fix them all up or compute that bit automagically (like we do for the has_volatile_ops flag). I assume that you _can_ determine if a stmt is part of a transaction (it may just not be a O(1) operation)? Thus, a bit crude way would be to have the gimple flag but have it to-be computed on-demand. And you'd compute it before critical passes such as LIM and PRE. > I t would seem appropriate to me that in the future, perhaps the CFG could > have a flag set for any basic block which is in a transaction... This would > make it pretty trivial at all times to tell if a statement is part of a > transaction or not. It seems like the process of CFG construction/updating > should be able to maintain that info for little cost. (ie, I'd guess it's > already making the traversals requires to collect that info) > > It would certainly be convenient :-) That would sound easier than maintaining the flag on the stmt. OTOH we already maintain on-the-side EH tables, so it can't be that big of a problem. What do we do if we move stmts inside a transaction though? Do they magically become part of it and thus we cannot move them out again? If you want to fix this issue for 4.7, add the gimple flag and an on-demand compute helper and check the flag in PRE/LIM. Richard. > Andrew > > >
