Displaying 20 results from an estimated 6000 matches similar to: "[LLVMdev] Curiosity about transform changes under Sanitizers (Was: [PATCH] Disable branch folding with MemorySanitizer)"
2013 Nov 19
0
[LLVMdev] Curiosity about transform changes under Sanitizers (Was: [PATCH] Disable branch folding with MemorySanitizer)
On Tue, Nov 19, 2013 at 8:25 PM, David Blaikie <dblaikie at gmail.com> wrote:
> Just moving this branch of the thread out of the review because I don't
> want to derail the review thread...
>
> Kostya - why are these two cases not optimization bugs in general? (why do
> they only affect sanitizers?)
>
The recent case from mozilla (
2013 Nov 19
3
[LLVMdev] Curiosity about transform changes under Sanitizers (Was: [PATCH] Disable branch folding with MemorySanitizer)
The root cause of those issues is the fact that sanitizers verify
C++-level semantics with LLVM IR level instrumentation. For example,
speculative loads are OK in IR if it can be proved that the load won't
trap, but in C++ it would be a data race.
On Tue, Nov 19, 2013 at 8:38 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>
>
> On Tue, Nov 19, 2013 at 8:25 PM, David
2013 Nov 19
5
[LLVMdev] Curiosity about transform changes under Sanitizers (Was: [PATCH] Disable branch folding with MemorySanitizer)
On Tue, Nov 19, 2013 at 9:05 PM, Kuperstein, Michael M <
michael.m.kuperstein at intel.com> wrote:
> My $0.02 - I'm not sure the transformation introduces a data race.
>
> To the best of my understanding, the point of the C++11/C11 memory model
> is to allow a wide array of compiler transformations - including
> speculative loads - for non-atomic variables.
> I believe
2013 Nov 19
1
[LLVMdev] Curiosity about transform changes under Sanitizers (Was: [PATCH] Disable branch folding with MemorySanitizer)
On Tue, Nov 19, 2013 at 8:38 AM, Kostya Serebryany <kcc at google.com> wrote:
>
>
>
> On Tue, Nov 19, 2013 at 8:25 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>> Just moving this branch of the thread out of the review because I don't
>> want to derail the review thread...
>>
>> Kostya - why are these two cases not optimization bugs in
2013 Nov 19
0
[LLVMdev] Curiosity about transform changes under Sanitizers (Was: [PATCH] Disable branch folding with MemorySanitizer)
What I'm trying to say is that according to my understanding of the C++11 memory model, even in that small reproducer, the store to g and the load from g are in fact a data race.
(This is regardless of the fact the load is protected by a branch that is not taken.)
From: Kostya Serebryany [mailto:kcc at google.com]
Sent: Tuesday, November 19, 2013 19:46
To: Kuperstein, Michael M
Cc: Evgeniy
2013 Nov 19
0
[LLVMdev] Curiosity about transform changes under Sanitizers (Was: [PATCH] Disable branch folding with MemorySanitizer)
My $0.02 - I'm not sure the transformation introduces a data race.
To the best of my understanding, the point of the C++11/C11 memory model is to allow a wide array of compiler transformations - including speculative loads - for non-atomic variables.
I believe what's most likely happening (without looking at the Mozilla source) is that the original program contains a C++ data race, and
2013 Nov 19
2
[LLVMdev] Curiosity about transform changes under Sanitizers (Was: [PATCH] Disable branch folding with MemorySanitizer)
On Tue, Nov 19, 2013 at 10:08 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
> > From: "Kostya Serebryany" <kcc at google.com>
> > To: "Michael M Kuperstein" <michael.m.kuperstein at intel.com>
> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> > Sent: Tuesday, November 19,
2013 Nov 19
0
[LLVMdev] Curiosity about transform changes under Sanitizers (Was: [PATCH] Disable branch folding with MemorySanitizer)
----- Original Message -----
> From: "Kostya Serebryany" <kcc at google.com>
> To: "Michael M Kuperstein" <michael.m.kuperstein at intel.com>
> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Tuesday, November 19, 2013 11:45:39 AM
> Subject: Re: [LLVMdev] Curiosity about transform changes under Sanitizers (Was:
2013 Nov 19
0
[LLVMdev] Curiosity about transform changes under Sanitizers (Was: [PATCH] Disable branch folding with MemorySanitizer)
----- Original Message -----
> From: "David Blaikie" <dblaikie at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Kostya Serebryany" <kcc at google.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Tuesday, November 19, 2013 12:19:46 PM
> Subject: Re: [LLVMdev] Curiosity about transform
2013 Nov 19
4
[LLVMdev] Curiosity about transform changes under Sanitizers (Was: [PATCH] Disable branch folding with MemorySanitizer)
On Tue, Nov 19, 2013 at 9:56 PM, Kuperstein, Michael M <
michael.m.kuperstein at intel.com> wrote:
> What I’m trying to say is that according to my understanding of the
> C++11 memory model, even in that small reproducer, the store to g and the
> load from g are in fact a data race.
>
> (This is regardless of the fact the load is protected by a branch that is
> not
2019 Sep 29
2
[cfe-dev] CFG simplification question, and preservation of branching in the original code
On Sun, Sep 29, 2019 at 3:35 PM Joan Lluch via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi Sanjay,
>
> Actually, the CodeGenPrepare::optimizeSelectInst is not doing the best it could do in some circumstances: The case of “OptSize" for targets not supporting Select was already mentioned to be detrimental.
>
> For targets that actually have selects, but branches
2019 Sep 30
3
[cfe-dev] CFG simplification question, and preservation of branching in the original code
On Mon, Sep 30, 2019 at 11:52 AM Joan Lluch <joan.lluch at icloud.com> wrote:
>
> Hi Roman,
>
> Is "test" actually an implementation of a 64-bit-wide multiplication
> compiler-rt builtin?
> Then i'd think the main problem is that it is being optimized in the
> first place, you could end up with endless recursion…
>
>
> No, this is not a compiler-rt
2017 Jul 06
2
Dataflow analysis regression in 3.7
On Thu, Jul 6, 2017 at 7:00 AM, Davide Italiano <davide at freebsd.org> wrote:
> On Wed, Jul 5, 2017 at 3:59 PM, Johan Engelen via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Hi all,
> > I just found an optimization regression regarding simple
> > dataflow/constprop analysis:
> > https://godbolt.org/g/Uz8P7t
> >
> > This code
>
2019 Sep 25
2
[cfe-dev] CFG simplification question, and preservation of branching in the original code
Changing the order of the checks in CodeGenPrepare::optimizeSelectInst()
sounds good to me.
But you may need to go further for optimum performance. For example, we may
be canonicalizing math/logic IR patterns into 'select' such as in the
recent:
https://reviews.llvm.org/D67799
So if you want those to become ALU ops again rather than branches, then you
need to do the transform later in
2019 Sep 30
2
[cfe-dev] CFG simplification question, and preservation of branching in the original code
For the MSP430 example, I'm guess its InstCombiner::transformSExtICmp
or InstCombiner::transformZExtICmp
~Craig
On Mon, Sep 30, 2019 at 2:21 PM Support IMAP <support at sweetwilliamsl.com>
wrote:
> Hi all,
>
> Ok, I just found a much simpler example of the same issue.
>
> Consider the following code
>
> int cmpge32_0(long a) {
> return a>=0;
> }
>
2019 Oct 01
3
[cfe-dev] CFG simplification question, and preservation of branching in the original code
Hi Sanjay,
Thanks for your reply.
> So yes, the IR optimizer (instcombine is the specific pass) sometimes turns icmp (and select) sequences into ALU ops. Instcombine is almost entirely *target-independent* and should remain that way. The (sometimes unfortunate) decision to create shifts were made based on popular targets of the time (PowerPC and/or x86), and other targets may have suffered
2014 Sep 19
2
[LLVMdev] poison and select
Today I ran into another aspect of the poison problem...
Basically, SimplifyCFG wants to take
expr1 && expr2
and flatten it into
x = expr1
y = expr2
x&y
This isn't safe when expr2 might execute UB. The consequence is that no
LLVM shift instruction is safe to speculatively execute, nor is any
nsw/nuw/exact variant, unless the operands can be proven to be in
2012 Mar 29
1
[LLVMdev] Problem recognizing nested select operations
Hello all,
I just noticed that LLVM has trouble recognizing nested simple select
operations.
My testcase is as follows:
-------------------------- snip ------------------------------
#include <stdio.h>
int main(int argc, char **argv)
{
int a;
scanf("%d", &a);
a = a > 255 ? 255 : a < 0 ? 0 : a;
printf("A: %d\n", a);
return 0;
}
2014 Nov 04
10
[LLVMdev] lifetime.start/end clarification
The LRM (http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic)
essentially states that:
- ptr is dead before a call to "lifetime.start size, ptr"
- ptr is dead after a call to "lifetime.end size, ptr"
This is all good and fine, and the expected use case is that all
"lifetime.end size, ptr" markers are matched with a preceding
"lifetime.start
2016 May 19
4
GEP index canonicalization
Hi,
InstCombine canonicalizes index operands (unless they are into struct
types) to pointer size. The comment says: "If we are using a wider
index than needed for this platform, shrink it to what we need. If
narrower, sign-extend it to what we need. This explicit cast can make
subsequent optimizations more obvious.".
For our architecture, the canonicalization is a bit