similar to: The nsw story revisited

Chandler, Please give some citations, I’ve search the llvm-dev archives and didn't find any. Peter Lawrence. > On Jun 28, 2017, at 12:01 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > > On Wed, Jun 28, 2017 at 9:39 AM Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> wrote: > > Preface: This paper

On 06/28/2017 02:18 PM, Chandler Carruth wrote: > On Wed, Jun 28, 2017 at 12:09 PM Peter Lawrence > <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> wrote: > > Chandler, > Please give some citations, I’ve search the > llvm-dev archives and didn't find any. > > > They are all in the discussions from Nuno,

John, Sanjoy, Nuno, David, Thanks for the tip, below are the relevant posts from the archives. I am suggesting something similar to Dan's third option below (Tue Nov 29 2011 "the nsw story”, Dan Gohman), when hoisting an instruction with ‘nsw’ it looses the ‘nsw’ attribute, but without saying “add-nsw is a fully side-effecting instruction”. This option was back then seen by

Sean, Many thanks for taking the time to respond. I didn’t make myself clear, I will try to be brief... > On Jun 28, 2017, at 7:48 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Wed, Jun 28, 2017 at 3:33 PM, Peter Lawrence via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Chandler, >

The old and popular tradition of "int" being the default all-purpose type in C hit a snag with the arrival of 64-bit general-purpose architectures, when, for reasons of memory usage and compatibility, "int" was fixed at 32 bits. This meant it was no longer the same size as a pointer, the size of an array index, or the widest native integer type. (Sequence of events simplified

Chandler, where we disagree is in whether the current project is moving the issue forward. It is not. It is making the compiler more complex for no additional value. The current project is not based in evidence, I have asked for any SPEC benchmark that shows performance gain by the compiler taking advantage of “undefined behavior” and no one can show that. The current project

Part I. The original LangRef appeared to be “nice and pretty” and originally ‘undef’ did not seem to stick out. Then evidence came to light in the form of bug reports, and in the form of Dan Gohman’s email “the nsw story”, that all was not good for ‘undef’ [1,2]. A proposal was made based on that evidence. A presentation was made at an llvm gathering. A paper was written. The proposal has even

Sanjoy, You have changed the subject. We still need real world examples showing how taking advantage of “undef” results in beneficial optimization. My belief is that they don’t exist, my reasoning is this: real world programmers are likely to run UBSan before compiling (or if they don’t they should), therefore it is highly unlikely that any “undef” will actually exist during

Hi Peter, On Thu, Jun 8, 2017 at 9:41 AM, Peter Lawrence <peterl95124 at sbcglobal.net> wrote: > >> On Jun 7, 2017, at 2:23 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: >> >> Since most add/sub operations compiled from C have the nsw attribute, we cannot simply restrict movement of these instructions. > > Nuno, > I’m not saying the operations

Since most add/sub operations compiled from C have the nsw attribute, we cannot simply restrict movement of these instructions. Sure, we could drop nsw when moving these instructions, but there are still many other problems left. Please read more about the topic here: https://blog.regehr.org/archives/1496 For example, doing loop unswitching, followed by inline (just to illustrate that the

A few thoughts from someone on the sidelines; hope they're helpful. On Tue, Nov 29, 2011 at 3:21 PM, Dan Gohman <gohman at apple.com> wrote: > The first solution for this was to define nsw add to return undef on > overflow, instead of invoking immediate undefined behavior. This way, > overflow can happen and it doesn't cause any harm unless the value > is actually used.

All, These discussions seem to be based on the premise that there is a need for the compiler to exploit undefined behavior for performance optimization reasons. So far the only beneficial optimization I am aware of that relies on some form of “undefined” is Dan Gohman’s original project for LP64 targets of promoting i32 induction variables to i64 and hoisting sign-extension out of the

(If this thread is becoming tiresome, let me know. This newbie is trying to understand some of what's going on; clearly you've thought about it way more than I have, and I can understand if you want to stop thinking about it!) On Mon, Dec 5, 2011 at 2:22 PM, Dan Gohman <gohman at apple.com> wrote: > On Dec 5, 2011, at 11:55 AM, Paul Robinson wrote: > > > > On Thu,

On Dec 6, 2011, at 10:07 AM, Paul Robinson wrote: > On Tue, Dec 6, 2011 at 9:06 AM, David A. Greene <greened at obbligato.org> wrote: > Dan Gohman <gohman at apple.com> writes: > > > For example, suppose we want to convert the && to &, and the ?: to a > > select, in this code: > > > > if (a && (b ? (c + d) : e)) { > > >

Sanjoy, My answer is that step 3, commuting the multiply with the sign-extends, is invalid, As this is what causes the `udiv` to fault. I think it is invalid with or without the “freeze”, why do you think step 3, the commute, without the “freeze" is valid ? Also, do you think you can come up with an example that does not depend on signed overflow being “undefined” ? Peter

On Tue, Dec 6, 2011 at 9:06 AM, David A. Greene <greened at obbligato.org>wrote: > Dan Gohman <gohman at apple.com> writes: > > > For example, suppose we want to convert the && to &, and the ?: to a > > select, in this code: > > > > if (a && (b ? (c + d) : e)) { > > > > because we have a CPU architecture with poor branch

2011/12/14 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>: >> We first perform a speculation transformation, hoisting all of the >> code above the %overflow_check branch: >> >>   %t0 = add nsw i32 %a, %b >>   %t1 = sext i32 %t0 to i64 >>   %t2 = ashr i64 %t1, 31 >>   %t3 = add i64 %t2, 1 >>   %t5 = icmp ult %t3, 2 >>   %t6 =

Dan Gohman <gohman at apple.com> writes: >> I'm not following. If the promotion to i64 produces a different value, >> then the nsw smeantic was violated, leading to undefined behavior, as >> you note. That that point all bets are off. Divide by zero certainly >> is a perfectly valid expression of undefined behavior. If we had a >> delayed check we would

On Dec 5, 2011, at 4:44 PM, Paul Robinson wrote: > (If this thread is becoming tiresome, let me know. This newbie is trying to > understand some of what's going on; clearly you've thought about it way more > than I have, and I can understand if you want to stop thinking about it!) > > On Mon, Dec 5, 2011 at 2:22 PM, Dan Gohman <gohman at apple.com> wrote: > On Dec

Chandler, Al right then, stay on topic, what do you actually think should be done about the fact that the current proposal will mis-compile the function-inlining example, and won’t be able to hoist a loop-invariat divide out of a loop. Peter Lawrence. > On Jun 28, 2017, at 11:03 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > > On Wed, Jun 28, 2017 at