similar to: [LLVMdev] unconditional branch folding

Hello guys, For single scalar pointer parameter, we have 'byval' to specify the pointee is not changed. But for base+range parameters like: declare void @_gfortran_transfer_integer_write(%struct.__st_parameter_dt*, i8*, i32) (This is the fortran runtime api to 'printf' one integer) The 2nd & 3rd args are used to specify the memory of that integer. I didn't find a

Simplifycfg doesn't get run by default even with -O3, but 'opt -simplifycfg' can do it. I'm looking to add this functionality to an optimizer program that uses the llvm libraries. What's the best way to do this? I don't really mind whether it becomes available as a command line option as in opt, or I need to hardcode it as always on. To make it available as a command line

Okay, as far as I can see looking through the output of that, the empty block isn't created near the end, it exists at the start and never goes away. On Sun, Sep 20, 2015 at 1:36 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Hi Russell, > > Can you run your IR though opt with -O3 and -print-after-all and see when > the block becomes empty?

Yes, that is what I was thinking. Should I report it as a bug? On Sun, Sep 20, 2015 at 2:31 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Russell Wallace" <russell.wallace at gmail.com> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> >

attached is the diff of vcprojs that need to be changed to fix the VS build as of revision: 51224. I don't know if this catches all the missing bits, but this does build all the way through. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msvs.patch URL:

Hi Dmitri, For what version of VS did you update the project files? Ted On May 17, 2008, at 3:00 PM, Dmitri Makarov wrote: > attached is the diff of vcprojs that need to be changed to fix the VS > build as of revision: 51224. > > I don't know if this catches all the missing bits, but this does build > all the way through. > > > Index: win32/Analysis/Analysis.vcproj

One thing I want to mention. I believe in the current legacy pass manager implementation only one MachineFunction ever exists at a time. It is deleted before the next MachineFunction is created. This is very important for memory usage. I think the MachineOutliner being in the pipeline may create an exception to this. I think the initial version of retpoline used a ModulePass and that had to be

On Wed, Jul 15, 2020 at 6:39 PM Chen, Yuanfang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Indeed, but there is a distinction about their position in the pipeline. We run opt & codegen pipeline separately, Why, though? Is there a reason why this inherently makes sense, or is it just a historical accident? At least to me it seems that it would make more sense to run all passes

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

> On Jul 15, 2020, at 12:28, Chen, Yuanfang <Yuanfang.Chen at sony.com> wrote: > > In codegen with NPM, I've made all codegen passes (IR or MIR pass) to be only driven by `llc`. Both due to the way NPM registering pass (on-demand&dynamic instead of static initialization in Legacy PM), and reduce the confusion about which tool (`llc` or `opt`) to test codegen IR passes. >

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 (

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

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?) On Mon, Nov 18, 2013 at 8:37 PM, Kostya Serebryany <kcc at google.com> wrote: > And we've been just informed by the mozilla folks about yet another case > of

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

Hi Matt, which analysis is this? ________________________________________ From: Matt Arsenault <whatmannerofburgeristhis at gmail.com> on behalf of Matt Arsenault <arsenm2 at gmail.com> Sent: Tuesday, July 21, 2020 12:02 PM To: Craig Topper Cc: Chen, Yuanfang; Nicolai Hähnle; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by new pass

----- 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:

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

On Sun, Apr 18, 2010 at 4:36 AM, Eugene Toder <eltoder at gmail.com> wrote: > According to documentation Twines should be used only for temporary > values and not stored, so allocating the in heap sounds wrong. Yes, in general you should never be naming Twine directly, except in the case where you need to make a Twine for an integer. All other uses should be considered poor style, as

----- 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

On 05/28/15 15:27, Yuanfang Chen wrote: > #define GET_BIT(lll) \ > // blah blah > > #define G(label1,label2) \ > { \ > // decent amount code \ > ... > while (1) { \ > GET_BIT(label2); \ > }; \ > } > > void f() { > if (..)