This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR middle-end/56108] handle transactions with ASMs in the first block
- From: Richard Henderson <rth at redhat dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 21 Feb 2013 09:45:26 -0800
- Subject: Re: [PR middle-end/56108] handle transactions with ASMs in the first block
- References: <5124ED5F.5050302@redhat.com>
On 02/20/2013 07:35 AM, Aldy Hernandez wrote:
> In the following test, the first statement of a relaxed transaction is
> an inline asm:
>
> __transaction_relaxed { __asm__(""); }
>
> Since we bypass inserting BUILT_IN_TM_IRREVOCABLE at the beginning of
> transactions that are sure to be irrevocable, later when we try to
> expand the transaction, we ICE when we encounter the inline asm.
>
> Currently, we bypass the TM_IRREVOCABLE call here:
>
> for (region = d->all_tm_regions; region; region = region->next)
> {
> /* If we're sure to go irrevocable, don't transform anything. */
> if (d->irrevocable_blocks_normal
> && bitmap_bit_p (d->irrevocable_blocks_normal,
> region->entry_block->index))
> {
> transaction_subcode_ior (region, GTMA_DOES_GO_IRREVOCABLE);
> transaction_subcode_ior (region, GTMA_MAY_ENTER_IRREVOCABLE);
> continue;
> }
>
> If I understand this correctly, ideally a transaction marked as
> doesGoIrrevocable shouldn't bother instrumenting the statements inside,
> since the runtime will go irrevocable immediately. In which case, we
> can elide the instrumentation altogether as the attached patch does.
>
> If my analysis is correct, then testsuite/gcc.dg/tm/memopt-1.c would
> surely go irrevocable, thus requiring no instrumentation, causing the
> memory optimizations to get skipped altogether. In which case, it's
> best to mark the function calls as safe, so they don't cause the
> transaction to become obviously irrevocable.
>
> Is this correct? If so, OK?
Yes, that's correct. The patch is ok.
r~