[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 pc at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #13 from pc at gcc dot gnu.org --- sorry, changed the state of this bug instead of another. resetting to "NEW".
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 pc at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||pc at gcc dot gnu.org
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 --- Comment #12 from torvald at gcc dot gnu.org --- Thanks for reporting that you are affected as well. Regarding your question about bumping the priority, one problem for the TM support in general has been to be able to judge how many users are out there, and whether they are interested in TM for in-production software or just toying around with it because it's something new. This holds for GCC's implementation, but also for the ISO C++ TM Technical Specification. Thus, if you or anyone else is interested in using TM for real, please share your feedback with me personally or ISO C++ Study Group 5 (https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/tm ; sending email to t...@isocpp.org might work even if you're not subscribed to this list, or it should at least end up in a moderation queue). Sharing your feedback will help us and Study Group 5.
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 --- Comment #11 from Paul Clarke --- We use TM for a multi-producer-multi-consumer queue implementation, and ran into the issue reported in this bug. (I had opened bug 77681 before discovering this report.) This report is surprisingly old. Is there any chance this could get bumped to higher priority?
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 Paul Clarke changed: What|Removed |Added CC||pc at us dot ibm.com --- Comment #10 from Paul Clarke --- *** Bug 77681 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 --- Comment #9 from torvald at gcc dot gnu.org --- Still fails with r232693. This seems to be another case of difficult ordering between TM passes and other passes. It makes sense that we don't inline tm_pure because we must not loose that information. always_inline is specified to produce an error when not inlining, but this shouldn't be much of a problem when considering code instrumented for transactions I suppose (can there be a case where lack of inlining causes a correctness problem?). Perhaps it's easiest if we clone the function if we see such a case, so that the solution can be different for TM-instrumented clones and normal code.
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 --- Comment #8 from andysem at mail dot ru --- We have a similar problem in Boost.Atomic: https://svn.boost.org/trac/boost/ticket/10204 There we mark all boost::atomic<> functions as always_inline to make sure the compiler sees the memory order arguments as constants as opposed to runtime values (otherwise the compiler just ignores memory order arguments and acts as if seq_cst was specified). As I understand, atomic intrinsics are transaction_unsafe, so should be Boost.Atomic functions as well, yet we still want them always_inline. Given this I don't quite understand the reason why a transaction_unsafe function can't be inlined into the caller; the caller is unsafe anyway, isn't it? Is there a solution for this problem on the source code level, except removing always_inline?
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 --- Comment #7 from torvald at gcc dot gnu.org --- A piece of code is tm_pure if, roughly, it doesn't need any instrumentation (e.g., in contrast to memory loads/stores). In the test case, I suppose that the compiler detects that it is tm_pure, but we also allow programmers to declare it. Ideally, tm_pure should be a property of a region of code that is preserved across optimizations (but where we don't move code into or out of tm_pure regions). That may require too much implementation effort (but perhaps we could reuse the TM regions for that, as a "no-TM" region?) Alternatively, we could not automatically mark always_inline functions also as tm_pure, and warn if always_inline is also annotated as tm_pure by the programmer. Other thoughts?
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rth at gcc dot gnu.org, ||torvald at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- I know next to nothing about tm_pure, CCing those that do know.
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
--- Comment #5 from Jan Hubicka ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
>
> --- Comment #4 from Uroš Bizjak ---
> The inlining is failed in ipa-inline.c, around line 294:
>
> /* TM pure functions should not be inlined into non-TM_pure
> functions. */
> else if (is_tm_pure (callee->symbol.decl)
>&& !is_tm_pure (e->caller->symbol.decl))
> {
> e->inline_failed = CIF_UNSPECIFIED;
> inlinable = false;
> }
Instead of CIF_UNSPECIFIED we should have warning/error for this case.
Jakub, what should be the behaviour when !tm_pure always_inline
is called from tm_pure function?
Honza
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
--- Comment #4 from Uroš Bizjak ---
The inlining is failed in ipa-inline.c, around line 294:
/* TM pure functions should not be inlined into non-TM_pure
functions. */
else if (is_tm_pure (callee->symbol.decl)
&& !is_tm_pure (e->caller->symbol.decl))
{
e->inline_failed = CIF_UNSPECIFIED;
inlinable = false;
}
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
Uroš Bizjak changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3 from Uroš Bizjak ---
Actually, the difference begins in _c.018t.einline.
-O2 -fgnu-tm:
;; Function main (main, funcdef_no=1, decl_uid=1878, symbol_order=1)
not inlinable: main/1 -> _mm_popcnt_u64/0,
Considering inline candidate _mm_popcnt_u64.
not inlinable: main/1 -> _mm_popcnt_u64/0,
Iterations: 0
main ()
{
int res;
int _4;
:
res_1 = _mm_popcnt_u64 (0);
printf ("Result res should be 0: %d\n", res_1);
_4 = 0;
return _4;
}
-O2:
;; Function main (main, funcdef_no=1, decl_uid=1722, symbol_order=1)
Inlining _mm_popcnt_u64 into main (always_inline).
Iterations: 0
Merging blocks 2 and 4
Merging blocks 2 and 3
Symbols to be put in SSA form
{ D.1735 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 3
Number of blocks to update: 2 ( 67%)
main ()
{
int D.1735;
int res;
int _4;
int _5;
:
_5 = 0;
_6 = _5;
res_1 = _6;
printf ("Result res should be 0: %d\n", res_1);
_4 = 0;
return _4;
}
Adding CC.
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
Uroš Bizjak changed:
What|Removed |Added
Component|middle-end |tree-optimization
--- Comment #2 from Uroš Bizjak ---
For some reason ccp1 pass doesn't fully propagate _mm_popcnt_u64 when -fgnu-tm
is in effect, leaving:
res_1 = _mm_popcnt_u64 (0);
printf ("Result res should be 0: %d\n", res_1);
return 0;
Without -fgnu-tm, the cpp1 tree dump reads:
printf ("Result res should be 0: %d\n", 0);
return 0;
