Mehdi,
I think the following was the point of the conversation,
That both those examples are illegal C programs.
They are both “undefined behavior” because they both
use a shift amount that is too large.
They both should have been rejected by the compiler
even though they weren’t.
Hal agrees wth this assessment,
That’s why we’re waiting for a more complete example.
My belief is that undefined behavior is an optimization hazard,
Not an optimization opportunity. Its just a belief, I could be proved
Wrong at any moment, but it feels right to me.
I would start looking for a more complete example myself, but my
Belief is so strong that "optimizing undefined behavior" seems
like a self-contradiction to me, and I don’t know where to
Even start looking.
I write compiler test programs in my spare time as a hobby,
(which someday I’d like to contribute to llvm)
So it’s not like I don’t have the knowledge or the inclination,
I just don’t know how to approach this problem.
You would think that since “optimization of undefined behavior”
Has become such a bedrock concept in llvm that by now some
Concrete examples would be readily at hand,
But this doesn’t seem to be the case.
So I’m eagerly awaiting Hal’s (or anyone else's) next email
That has a complete example.
Peter Lawrence.
>>>>
>>>> I can't comment on SPEC, but this does remind me of code I
was working on recently. To abstract the relevant parts, it looked something
like this:
>>>>
>>>> template <typename T>
>>>> int do_something(T mask, bool cond) {
>>>> if (mask & 2)
>>>> return 1;
>>>>
>>>> if (cond) {
>>>> T high_mask = mask >> 48;
>>>> if (high_mask > 5)
>>>> do_something_1(high_mask);
>>>> else if (high_mask > 3)
>>>> do_something_2();
>>>> }
>>>>
>>>> return 0;
>>>> }
>>>>
>>>> This function ended up being instantiated on different types T
(e.g. unsigned char, unsigned int, unsigned long, etc.) and, dynamically, cond
was always false when T was char. The question is: Can the compiler eliminate
all of the code predicated on cond for the smaller types? In this case, this
code was hot, and moreover, performance depended on the fact that, for T =
unsigned char, the function was inlined and the branch on cond was eliminated.
In the relevant translation unit, however, the compiler would never see how cond
was set.
>>>>
>>>> Luckily, we do the right thing here currently. In the case
where T = unsigned char, we end up folding both of the high_mask tests as though
they were false. That entire part of the code is eliminated, the function is
inlined, and everyone is happy.
>>>>
>>>> Why was I looking at this? As it turns out, if the 'else
if' in this example is just 'else', we don't actually eliminate
both sides of the branch. The same is true for many other variants of the
conditionals (i.e. we don't recognize all of the code as dead).
>>>
>>>
>>> I apologize in advance if I have missed something here and am
misreading your example...
>>>
>>> This doesn’t make sense to me, a shift amount of 48 is “undefined”
for unsigned char,
>>> How do we know this isn’t a source code bug,
>>> What makes us think the the user intended the result to be “0”.
>>
>> As I said, this is representation of what the real code did, and looked
like, after other inlining had taken place, etc. In the original form, the
user's intent was clear. That code is never executed when T is a small
integer type.
>
>
> I will still have a hard time believing this until I see a real example,
can you fill in the details ?
>
>
> Hal gave you a real example, have you tried? I feel like you're asking
more effort from others than you are ready to put in: it took me less than 5
minutes to reproduce what Hal was describing using his snippet:
>
> See the difference between https://godbolt.org/g/YYtsxB
<https://godbolt.org/g/YYtsxB> and https://godbolt.org/g/dTBBDq
<https://godbolt.org/g/dTBBDq>
>
> --
> Mehdi
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170629/e91d4d21/attachment.html>
2017-06-29 14:32 GMT-07:00 Peter Lawrence <peterl95124 at sbcglobal.net>:> Mehdi, > I think the following was the point of the conversation, > That both those examples are illegal C programs. > They are both “undefined behavior” because they both > use a shift amount that is too large. >Can you confirm that even if the shift isn't executed the program exhibits undefined behavior? That wasn't my understanding, so I don't believe this program exhibits UB.> They both should have been rejected by the compiler > even though they weren’t. > Hal agrees wth this assessment, >I'm surprise by the confidence you're exhibiting while speaking for others. -- Mehdi> That’s why we’re waiting for a more complete example. > > My belief is that undefined behavior is an optimization hazard, > Not an optimization opportunity. Its just a belief, I could be proved > Wrong at any moment, but it feels right to me. > > I would start looking for a more complete example myself, but my > Belief is so strong that "optimizing undefined behavior" seems > like a self-contradiction to me, and I don’t know where to > Even start looking. > > I write compiler test programs in my spare time as a hobby, > (which someday I’d like to contribute to llvm) > So it’s not like I don’t have the knowledge or the inclination, > I just don’t know how to approach this problem. > > > You would think that since “optimization of undefined behavior” > Has become such a bedrock concept in llvm that by now some > Concrete examples would be readily at hand, > But this doesn’t seem to be the case. > > So I’m eagerly awaiting Hal’s (or anyone else's) next email > That has a complete example. > > > Peter Lawrence. > > > >> I can't comment on SPEC, but this does remind me of code I was working on >> recently. To abstract the relevant parts, it looked something like this: >> >> template <typename T> >> int do_something(T mask, bool cond) { >> if (mask & 2) >> return 1; >> >> if (cond) { >> T high_mask = mask >> 48; >> if (high_mask > 5) >> do_something_1(high_mask); >> else if (high_mask > 3) >> do_something_2(); >> } >> >> return 0; >> } >> >> This function ended up being instantiated on different types T (e.g. >> unsigned char, unsigned int, unsigned long, etc.) and, dynamically, cond >> was always false when T was char. The question is: Can the compiler >> eliminate all of the code predicated on cond for the smaller types? In this >> case, this code was hot, and moreover, performance depended on the fact >> that, for T = unsigned char, the function was inlined and the branch on >> cond was eliminated. In the relevant translation unit, however, the >> compiler would never see how cond was set. >> >> Luckily, we do the right thing here currently. In the case where T >> unsigned char, we end up folding both of the high_mask tests as though they >> were false. That entire part of the code is eliminated, the function is >> inlined, and everyone is happy. >> >> Why was I looking at this? As it turns out, if the 'else if' in this >> example is just 'else', we don't actually eliminate both sides of the >> branch. The same is true for many other variants of the conditionals (i.e. >> we don't recognize all of the code as dead). >> >> >> >> I apologize in advance if I have missed something here and am misreading >> your example... >> >> This doesn’t make sense to me, a shift amount of 48 is “undefined” for >> unsigned char, >> How do we know this isn’t a source code bug, >> What makes us think the the user intended the result to be “0”. >> >> >> As I said, this is representation of what the real code did, and looked >> like, after other inlining had taken place, etc. In the original form, the >> user's intent was clear. That code is never executed when T is a small >> integer type. >> >> >> >> I will still have a hard time believing this until I see a real example, >> can you fill in the details ? >> > > > Hal gave you a real example, have you tried? I feel like you're asking > more effort from others than you are ready to put in: it took me less than > 5 minutes to reproduce what Hal was describing using his snippet: > > See the difference between https://godbolt.org/g/YYtsxB and > https://godbolt.org/g/dTBBDq > > -- > Mehdi > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170629/d64ceb77/attachment.html>
On Thu, Jun 29, 2017 at 2:52 PM Peter Lawrence via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I would start looking for a more complete example myself, but my > Belief is so strong that "optimizing undefined behavior" seems > like a self-contradiction to me, and I don’t know where to > Even start looking. >If you can't take the time to provide evidence to back up your belief, then...> So I’m eagerly awaiting Hal’s (or anyone else's) next email > That has a complete example. >... I don't think it is reasonable to expect others to take their time. I understand you have this belief and find it incompatible with the LLVM community. I think several folks have tried to persuade you that there is merit in the design of LLVM here, but I understand you remain unconvinced. Perhaps you will start a compiler project based on your convictions here and develop it and show why that is a better way to start a compiler project. But without actually contributing to LLVM and showing clearly (and incrementally) how to improve it based on your belief with evidence to back it up, I don't think reiterating your belief on the list is a productive thing to do. -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170629/bce68186/attachment-0001.html>
On 06/29/2017 04:49 PM, Mehdi AMINI wrote:> > > 2017-06-29 14:32 GMT-07:00 Peter Lawrence <peterl95124 at sbcglobal.net > <mailto:peterl95124 at sbcglobal.net>>: > > Mehdi, > I think the following was the point of the conversation, > That both those examples are illegal C programs. > They are both “undefined behavior” because they both > use a shift amount that is too large. > > > Can you confirm that even if the shift isn't executed the program > exhibits undefined behavior? > That wasn't my understanding, so I don't believe this program exhibits UB.That's correct. The program does not exhibit UB. The too-large-shift is never dynamically reached. Furthermore, that's the point. Using the fact that we assume the program does not have UB, and the program did not have UB, to prune dead code out of some of the instantiated templates, was a good thing. Regarding whether it should be rejected by the compiler, it shouldn't. If you put the source I put in the email through Clang, it will indeed warn about the shift amount. A user is free to use -Werror, or similar, if they'd like such warnings to be an error. In the real code, the shift amount was only available after inlining, so the frontend could not have generated a warning or error directly. -Hal> > They both should have been rejected by the compiler > even though they weren’t. > Hal agrees wth this assessment, > > > I'm surprise by the confidence you're exhibiting while speaking for > others. > > -- > Mehdi > > That’s why we’re waiting for a more complete example. > > My belief is that undefined behavior is an optimization hazard, > Not an optimization opportunity. Its just a belief, I could be proved > Wrong at any moment, but it feels right to me. > > I would start looking for a more complete example myself, but my > Belief is so strong that "optimizing undefined behavior" seems > like a self-contradiction to me, and I don’t know where to > Even start looking. > > I write compiler test programs in my spare time as a hobby, > (which someday I’d like to contribute to llvm) > So it’s not like I don’t have the knowledge or the inclination, > I just don’t know how to approach this problem. > > > You would think that since “optimization of undefined behavior” > Has become such a bedrock concept in llvm that by now some > Concrete examples would be readily at hand, > But this doesn’t seem to be the case. > > So I’m eagerly awaiting Hal’s (or anyone else's) next email > That has a complete example. > > > Peter Lawrence. > > >>>>> >>>>> I can't comment on SPEC, but this does remind me of code I >>>>> was working on recently. To abstract the relevant parts, >>>>> it looked something like this: >>>>> >>>>> template <typename T> >>>>> int do_something(T mask, bool cond) { >>>>> if (mask & 2) >>>>> return 1; >>>>> >>>>> if (cond) { >>>>> T high_mask = mask >> 48; >>>>> if (high_mask > 5) >>>>> do_something_1(high_mask); >>>>> else if (high_mask > 3) >>>>> do_something_2(); >>>>> } >>>>> >>>>> return 0; >>>>> } >>>>> >>>>> This function ended up being instantiated on different >>>>> types T (e.g. unsigned char, unsigned int, unsigned long, >>>>> etc.) and, dynamically, cond was always false when T was >>>>> char. The question is: Can the compiler eliminate all of >>>>> the code predicated on cond for the smaller types? In this >>>>> case, this code was hot, and moreover, performance >>>>> depended on the fact that, for T = unsigned char, the >>>>> function was inlined and the branch on cond was >>>>> eliminated. In the relevant translation unit, however, the >>>>> compiler would never see how cond was set. >>>>> >>>>> Luckily, we do the right thing here currently. In the case >>>>> where T = unsigned char, we end up folding both of the >>>>> high_mask tests as though they were false. That entire >>>>> part of the code is eliminated, the function is inlined, >>>>> and everyone is happy. >>>>> >>>>> Why was I looking at this? As it turns out, if the 'else >>>>> if' in this example is just 'else', we don't actually >>>>> eliminate both sides of the branch. The same is true for >>>>> many other variants of the conditionals (i.e. we don't >>>>> recognize all of the code as dead). >>>> >>>> >>>> I apologize in advance if I have missed something here and >>>> am misreading your example... >>>> >>>> This doesn’t make sense to me, a shift amount of 48 is >>>> “undefined” for unsigned char, >>>> How do we know this isn’t a source code bug, >>>> What makes us think the the user intended the result to be “0”. >>> >>> As I said, this is representation of what the real code did, >>> and looked like, after other inlining had taken place, etc. >>> In the original form, the user's intent was clear. That code >>> is never executed when T is a small integer type. >> >> >> I will still have a hard time believing this until I see a >> real example, can you fill in the details ? >> >> >> >> Hal gave you a real example, have you tried? I feel like you're >> asking more effort from others than you are ready to put in: it >> took me less than 5 minutes to reproduce what Hal was describing >> using his snippet: >> >> See the difference between https://godbolt.org/g/YYtsxB and >> https://godbolt.org/g/dTBBDq <https://godbolt.org/g/dTBBDq> >> >> -- >> Mehdi >> >> >> > >-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170629/8f973d7d/attachment.html>
On 06/29/2017 04:56 PM, Chandler Carruth via llvm-dev wrote:> On Thu, Jun 29, 2017 at 2:52 PM Peter Lawrence via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > I would start looking for a more complete example myself, but my > Belief is so strong that "optimizing undefined behavior" seems > like a self-contradiction to me, and I don’t know where to > Even start looking. >To be clear (and to reiterate what Sanjoy said), you're not looking for optimization *of* UB. You're looking for optimizing on the basis of the assumption that the UB is not dynamically reachable. In some contexts you can think of this as an assumption that undef/poison values don't contribute to any observable side effects of the program. -Hal> > If you can't take the time to provide evidence to back up your belief, > then... > > So I’m eagerly awaiting Hal’s (or anyone else's) next email > That has a complete example. > > > ... I don't think it is reasonable to expect others to take their time. > > I understand you have this belief and find it incompatible with the > LLVM community. I think several folks have tried to persuade you that > there is merit in the design of LLVM here, but I understand you remain > unconvinced. > > Perhaps you will start a compiler project based on your convictions > here and develop it and show why that is a better way to start a > compiler project. But without actually contributing to LLVM and > showing clearly (and incrementally) how to improve it based on your > belief with evidence to back it up, I don't think reiterating your > belief on the list is a productive thing to do. > > -Chandler > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170629/86363ee7/attachment.html>
On Thu, Jun 29, 2017 at 2:32 PM, Peter Lawrence via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Mehdi, > I think the following was the point of the conversation, > That both those examples are illegal C programs. > They are both “undefined behavior” because they both > use a shift amount that is too large. > They both should have been rejected by the compiler > even though they weren’t. > Hal agrees wth this assessment, > That’s why we’re waiting for a more complete example. > > My belief is that undefined behavior is an optimization hazard, > Not an optimization opportunity. Its just a belief, I could be proved > Wrong at any moment, but it feels right to me. > > I would start looking for a more complete example myself, but my > Belief is so strong that "optimizing undefined behavior" seems > like a self-contradiction to me, and I don’t know where to > Even start looking. > > I write compiler test programs in my spare time as a hobby, > (which someday I’d like to contribute to llvm) > So it’s not like I don’t have the knowledge or the inclination, > I just don’t know how to approach this problem. >Hi Peter, were you able to get set up with LLVM's test-suite? As Tim helpfully mentioned, you should be able to compile test-suite as 32-bit on your Mac without issues by using the -m32 flag like usual. Once you have that set up and have measured the performance impact of -fwrapv, pinpointing the causes of any regressions would be a good place to start. I understand that you feel like you have a strong intuition about this and aren't expecting any regressions, but you really need to put that to the test for us to take you seriously, as our intuition is the opposite (and usually backed up by specific examples from our professional experience, like the example that Hal mentioned). -- Sean Silva> > You would think that since “optimization of undefined behavior” > Has become such a bedrock concept in llvm that by now some > Concrete examples would be readily at hand, > But this doesn’t seem to be the case. > > So I’m eagerly awaiting Hal’s (or anyone else's) next email > That has a complete example. > > > Peter Lawrence. > > > >> I can't comment on SPEC, but this does remind me of code I was working on >> recently. To abstract the relevant parts, it looked something like this: >> >> template <typename T> >> int do_something(T mask, bool cond) { >> if (mask & 2) >> return 1; >> >> if (cond) { >> T high_mask = mask >> 48; >> if (high_mask > 5) >> do_something_1(high_mask); >> else if (high_mask > 3) >> do_something_2(); >> } >> >> return 0; >> } >> >> This function ended up being instantiated on different types T (e.g. >> unsigned char, unsigned int, unsigned long, etc.) and, dynamically, cond >> was always false when T was char. The question is: Can the compiler >> eliminate all of the code predicated on cond for the smaller types? In this >> case, this code was hot, and moreover, performance depended on the fact >> that, for T = unsigned char, the function was inlined and the branch on >> cond was eliminated. In the relevant translation unit, however, the >> compiler would never see how cond was set. >> >> Luckily, we do the right thing here currently. In the case where T >> unsigned char, we end up folding both of the high_mask tests as though they >> were false. That entire part of the code is eliminated, the function is >> inlined, and everyone is happy. >> >> Why was I looking at this? As it turns out, if the 'else if' in this >> example is just 'else', we don't actually eliminate both sides of the >> branch. The same is true for many other variants of the conditionals (i.e. >> we don't recognize all of the code as dead). >> >> >> >> I apologize in advance if I have missed something here and am misreading >> your example... >> >> This doesn’t make sense to me, a shift amount of 48 is “undefined” for >> unsigned char, >> How do we know this isn’t a source code bug, >> What makes us think the the user intended the result to be “0”. >> >> >> As I said, this is representation of what the real code did, and looked >> like, after other inlining had taken place, etc. In the original form, the >> user's intent was clear. That code is never executed when T is a small >> integer type. >> >> >> >> I will still have a hard time believing this until I see a real example, >> can you fill in the details ? >> > > > Hal gave you a real example, have you tried? I feel like you're asking > more effort from others than you are ready to put in: it took me less than > 5 minutes to reproduce what Hal was describing using his snippet: > > See the difference between https://godbolt.org/g/YYtsxB and > https://godbolt.org/g/dTBBDq > > -- > Mehdi > > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170629/df53e689/attachment.html>
Hal,
Mehdi points out I mis-quoted you, I apologize sincerely.
Mehdi,
Thank you for forcing me to go back and re-read what Hal wrote,
I could have sworn Hal and I were in agreement at the time I wrote you,
Must have been asleep at the wheel, not enough sleep last night
However my request for a more concrete example stands
Here’s what I said> This doesn’t make sense to me, a shift amount of 48 is “undefined” for
unsigned char,
> How do we know this isn’t a source code bug,
> What makes us think the the user intended the result to be “0”.
Here’s what Hal said in response> As I said, this is representation of what the real code did, and looked
like, after other
> inlining had taken place, etc. In the original form, the user's intent
was
> clear. That code is never executed when T is a small integer type.
The problem is I don’t know how to interpret what Hal said here,
I can’t construct the “real” example from the “representative” example
given his advise.
If by “that code” he means the “if(cond)” code then the only way I see that
the user can make it clear that “that code” is never execute is if “cond” is
always false. But if “cond” is always false then the if-statement is just plain
old dead code, has nothing to do with undefined behavior.
So I am puzzled,
That’s why I’m still asking for a more concrete example showing how
We can optimize based on undefined behavior.
Peter Lawrence.
For reference here’s your second version with the plain “else” rather than “else
if"
void do_something_1(int);
void do_something_2();
template <typename T>
int do_something(T mask, bool cond) {
if (mask & 2)
return 42;
if (cond) {
T high_mask = mask >> 48;
if (high_mask > 5)
do_something_1(high_mask);
else
do_something_2();
}
return 0;
}
char foo();
bool alwaysfalse();
char f = do_something<char>(foo(), alwaysfalse());
> On Jun 29, 2017, at 2:49 PM, Mehdi AMINI <joker.eph at gmail.com>
wrote:
>
>
>
> 2017-06-29 14:32 GMT-07:00 Peter Lawrence <peterl95124 at sbcglobal.net
<mailto:peterl95124 at sbcglobal.net>>:
> Mehdi,
> I think the following was the point of the conversation,
> That both those examples are illegal C programs.
> They are both “undefined behavior” because they both
> use a shift amount that is too large.
>
> Can you confirm that even if the shift isn't executed the program
exhibits undefined behavior?
> That wasn't my understanding, so I don't believe this program
exhibits UB.
>
>
> They both should have been rejected by the compiler
> even though they weren’t.
> Hal agrees wth this assessment,
>
> I'm surprise by the confidence you're exhibiting while speaking for
others.
>
> --
> Mehdi
>
>
> That’s why we’re waiting for a more complete example.
>
> My belief is that undefined behavior is an optimization hazard,
> Not an optimization opportunity. Its just a belief, I could be proved
> Wrong at any moment, but it feels right to me.
>
> I would start looking for a more complete example myself, but my
> Belief is so strong that "optimizing undefined behavior" seems
> like a self-contradiction to me, and I don’t know where to
> Even start looking.
>
> I write compiler test programs in my spare time as a hobby,
> (which someday I’d like to contribute to llvm)
> So it’s not like I don’t have the knowledge or the inclination,
> I just don’t know how to approach this problem.
>
>
> You would think that since “optimization of undefined behavior”
> Has become such a bedrock concept in llvm that by now some
> Concrete examples would be readily at hand,
> But this doesn’t seem to be the case.
>
> So I’m eagerly awaiting Hal’s (or anyone else's) next email
> That has a complete example.
>
>
> Peter Lawrence.
>
>
>>>>>
>>>>> I can't comment on SPEC, but this does remind me of
code I was working on recently. To abstract the relevant parts, it looked
something like this:
>>>>>
>>>>> template <typename T>
>>>>> int do_something(T mask, bool cond) {
>>>>> if (mask & 2)
>>>>> return 1;
>>>>>
>>>>> if (cond) {
>>>>> T high_mask = mask >> 48;
>>>>> if (high_mask > 5)
>>>>> do_something_1(high_mask);
>>>>> else if (high_mask > 3)
>>>>> do_something_2();
>>>>> }
>>>>>
>>>>> return 0;
>>>>> }
>>>>>
>>>>> This function ended up being instantiated on different
types T (e.g. unsigned char, unsigned int, unsigned long, etc.) and,
dynamically, cond was always false when T was char. The question is: Can the
compiler eliminate all of the code predicated on cond for the smaller types? In
this case, this code was hot, and moreover, performance depended on the fact
that, for T = unsigned char, the function was inlined and the branch on cond was
eliminated. In the relevant translation unit, however, the compiler would never
see how cond was set.
>>>>>
>>>>> Luckily, we do the right thing here currently. In the case
where T = unsigned char, we end up folding both of the high_mask tests as though
they were false. That entire part of the code is eliminated, the function is
inlined, and everyone is happy.
>>>>>
>>>>> Why was I looking at this? As it turns out, if the
'else if' in this example is just 'else', we don't actually
eliminate both sides of the branch. The same is true for many other variants of
the conditionals (i.e. we don't recognize all of the code as dead).
>>>>
>>>>
>>>> I apologize in advance if I have missed something here and am
misreading your example...
>>>>
>>>> This doesn’t make sense to me, a shift amount of 48 is
“undefined” for unsigned char,
>>>> How do we know this isn’t a source code bug,
>>>> What makes us think the the user intended the result to be “0”.
>>>
>>> As I said, this is representation of what the real code did, and
looked like, after other inlining had taken place, etc. In the original form,
the user's intent was clear. That code is never executed when T is a small
integer type.
>>
>>
>> I will still have a hard time believing this until I see a real
example, can you fill in the details ?
>>
>>
>> Hal gave you a real example, have you tried? I feel like you're
asking more effort from others than you are ready to put in: it took me less
than 5 minutes to reproduce what Hal was describing using his snippet:
>>
>> See the difference between https://godbolt.org/g/YYtsxB
<https://godbolt.org/g/YYtsxB> and https://godbolt.org/g/dTBBDq
<https://godbolt.org/g/dTBBDq>
>>
>> --
>> Mehdi
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170629/af56418a/attachment.html>