search for: morisset

Hi Robin, On 15 August 2014 21:49, Robin Morisset <morisset at google.com> wrote: > I have > attached the corresponding patches; they are not completely ready for review > (mostly missing tests), I would just like to make sure that the general > approach seems reasonable. I've had a quick glance at the patches, and the code...

On Thu, Oct 30, 2014 at 2:33 PM, Robin Morisset <morisset at google.com> wrote: > Hi, > > From my understanding of the LLVM IR, it is impossible to jump to the > middle of a Basic Block, only to its beginning. But there is a > splitBasicBlock function that seems like it might be useful to you, to make > sure a basic bloc...

...d by loop rotate pass. Since LICM runs after loop rotate, we can use ScalarEvolution::isLoopEntryGuardedByCond to check if we can speculatively execute load without causing a race. Is it heavy-handed solution for this problem? I can create a bug if you would like to. Thanks, Balaram From: Robin Morisset [mailto:morisset at google.com] Sent: Tuesday, September 02, 2014 7:40 PM To: Filip Pizlo Cc: Balaram Makam; LLVM Developers Mailing List Subject: Re: [LLVMdev] LICM promoting memory to scalar Ah right, I had missed the cbz, my bad. It is indeed sound under that condition. My point was that just...

On Thu, Oct 30, 2014 at 4:48 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Thu Oct 30 2014 at 1:16:38 PM Xiaoguang Wang <xgwang09 at gmail.com> > wrote: > >> On Thu, Oct 30, 2014 at 2:33 PM, Robin Morisset <morisset at google.com> >> wrote: >> >>> Hi, >>> >>> From my understanding of the LLVM IR, it is impossible to jump to the >>> middle of a Basic Block, only to its beginning. But there is a >>> splitBasicBlock function that seems like...

...he last store. How's that unsafe? If I had to guess, the bug here is that LLVM doesn't want to hoist the load over the condition (which it is right to want to avoid) but it fails to realize that the condition is true for the first iteration. -Filip > On Sep 2, 2014, at 4:23 PM, Robin Morisset <morisset at google.com> wrote: > > The problem here is that doing this can introduce a race which is undefined at the IR level. > In the example you gave above I suspect that this is a bug in GCC. I may have missed something in the assembly, but it appears that gcc loads a copy of...

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Robin Morisset" <morisset at google.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "James Molloy" <james at jamesmolloy.co.uk>, "LLVM Developers Mailing List" > <llvmdev at cs.uiuc.edu> > Sent: Tuesday, October 14, 2014 4:09:11 PM > Subject: Re...

For what it is worth, I agree with the usefulness of having a concept of "cleanup pass". Another example of a situation where it would be nice is in the fence elimination patch I sent for review recently: the pass is rather expensive because it relies on several analysis passes, and is only useful if AtomicExpand introduced fences. Being able to say "Only run this pass if the code

> From my reading of Atomics.rst, it would be sound to reorder (It does not > say much about load-linked, so I am treating it as a normal load here) > >> store seq_cst >> fence release >> load-linked monotonic > > into > >> load-linked monotonic >> store seq_cst >> fence release > Which would make an execution ending in %old_x = %old_y = 0

Hi all, I'm a beginner in LLVM. Currently, I want to implement a pass that generates a jump table. The entry in that table is a jump to some place (may be an instruction) in a basic block. I'm reading the JumpTable code in llvm 3.5, there is a table which contains jump entries to functions. In AsmPrinter::doFinalization function from file lib/CodeGen/AsmPrinter/AsmPrinter.cpp, it gets a

Hi everyone, The OpenMP standards committee has begun work to formalize their memory model, and define its relationship to the C/C++ memory models. A questionnaire has been put together (pasted below), and I'd like everyone's help in composing detailed answers to inform their decision-making process. While our OpenMP support is still in active development, many of these questions apply

...RM backend with a kind of PRE algorithm. Both of these improvements to the ARM backend should be fairly straightforward to port to the POWER architecture later, and I hope to also do that. Does this approach seem worthwhile to you ? Can I do anything to help the review process ? Thank you, Robin Morisset -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140805/ae4e3091/attachment.html>

All, If we can speculatively execute a load instruction, why isn’t it safe to hoist it out by promoting it to a scalar in LICM pass? There is a comment in LICM pass that if a load/store is conditional then it is not safe because it would break the LLVM concurrency model (See commit 73bfa4a). It has an IR test for checking this in test/Transforms/LICM/scalar-promote-memmodel.ll However, I have

...ompiled for different architectures](http://article.gmane.org/gmane.comp.compilers.clang.devel/39084). All executables are statically linked with musl and compiler-rt. ## LLVM commits * Segmented stacks support for the x32 ABI has been fixed. [r218427](http://reviews.llvm.org/rL218427). * Robin Morisset's work on optimisation of atomics continues. AtomicExpandPass now inserts fences itself rather than SelectionDAGBuilder. [r218329](http://reviews.llvm.org/rL218329). * LLVM's libSupport gained a type-safe alternative to `llvm::format()`. [r218463](http://reviews.llvm.org/rL218463). * llvm...

> Longer term, I hope to improve the fence elimination of the ARM backend with > a kind of PRE algorithm. Both of these improvements to the ARM backend > should be fairly straightforward to port to the POWER architecture later, > and I hope to also do that. > > Any reason these couldn't be done at the IR level? I definitely agree here. At the time, it was a plausible idea

> I am planning in doing in IR, but with target specific-passes (such as X86ExpandAtomicPass) > that just share some of the code This would more normally be done via target hooks in LLVM, though the principle is sound. > But it must be target-dependent as for example on Power a > seq_cst store has a fence before it, while on ARM it has a fence > both before and after it (per