search for: hammocks

Message: 6 Date: Tue, 6 Aug 2013 10:46:19 -0400 From: Chad Rosier <chad.rosier at gmail.com<mailto:chad.rosier at gmail.com>> To: llvmdev <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>> Subject: [LLVMdev] Potential SimplifyCFG optimization; hammock to diamond transformation Message-ID: <CAMo3wbR6x1wBzb17=GrkERV7kvzx2RdpuheFzyxkQEs3BBvKaw at

The specific code I'm looking at does not have any function calls. The "lots of FP math" is just a series of FP addition, subtraction and division. On Tue, Aug 6, 2013 at 11:03 AM, David Tweed <david.tweed at arm.com> wrote: > Hi,**** > > ** ** > > I imagine this optimization is for FP math stuff that doesn't involve > functions which might set errno

All, I have some code that looks like the following: { double a, b, c; for (...) { ... a = lots of FP math; b = lots of FP math; c = lots of FP math; if (cond) { a = 0.0; b = 0.1; c = 0.2; } ... } } Could we not convert the hammock into a diamond and move the initial computation of a, b, and c into the else block. Something like this: {

Hi Chad, On Aug 6, 2013, at 7:46 AM, Chad Rosier <chad.rosier at gmail.com> wrote: > All, > I have some code that looks like the following: > > { > double a, b, c; > for (...) { > ... > a = lots of FP math; > b = lots of FP math; > c = lots of FP math; > if (cond) { > a = 0.0; > b = 0.1; > c = 0.2; >

Thanks, Mark. I will give the paper a look. On Tue, Aug 6, 2013 at 1:42 PM, Mark Lacey <mark.lacey at apple.com> wrote: > Hi Chad, > > On Aug 6, 2013, at 7:46 AM, Chad Rosier <chad.rosier at gmail.com> wrote: > > > All, > > I have some code that looks like the following: > > > > { > > double a, b, c; > > for (...) { > >

Alright, I can now see my hammocks being translated into phi nodes. Thanx for the info. I now have a question regarding the analyze tool. I noticed it has a -help option. I tried using the -print-cfg option. It creates a cfg.main.dot file. Is there a graphical tool I can use to view this graph ? Thanx, -- Vinay S. Belgaumkar

...esn't actually help, AFAICT). My first attempt at solving this problem did something similar to what is done in JumpThreadingPass::ProcessImpliedCondition(). Specifically, it tried to prove that dst_ptr was non-null based on a dominating condition. The only tricky parts were to deal with hammocks/diamonds when walking up the CFG (See: https://reviews.llvm.org/D36287 as a concrete example of how I proposed to get an immediate dominator without the domtree) and to account for the fact that dst_ptr and a_ptr are equal. I'm pretty sure I can get this approach to work, however, I'm n...

...tell you why it did not vectorize; e.g., if some instruction was not available in vector form. So the vectorizer takes care of any desired unrollings on its own, and does not rely on a separate unroll pass. It does rely on a separate if-conversion pass especially designed to eliminate if-then-else hammocks in relevant regions (loops) right before the vectorizer kicks in. This part may require undoing, when an if-converted loop is not vectorized and the target does not support the resulting predicated scalar instructions. Hope this helps. Had the pleasure of working with the GCC autovect guys (or rat...

Hi guys! I'm getting the following warn on 4.15-rc1, on GTX 560 Ti: [ 9.430433] nouveau 0000:01:00.0: NVIDIA GF114 (0ce000a1) ... [ 9.585172] nouveau 0000:01:00.0: bios: version 70.24.2e.00.02 ... [ 9.772204] nouveau 0000:01:00.0: fb: 1024 MiB GDDR5 [ 9.777342] ------------[ cut here ]------------ [ 9.782106] refcount_t: increment on 0; use-after-free. [ 9.787522] WARNING:

...P doesn't actually help, AFAICT). My first attempt at solving this problem did something similar to what is done in JumpThreadingPass::ProcessImpliedCondition(). Specifically, it tried to prove that dst_ptr was non-null based on a dominating condition. The only tricky parts were to deal with hammocks/diamonds when walking up the CFG (See: https://reviews.llvm.org/D36287 as a concrete example of how I proposed to get an immediate dominator without the domtree) and to account for the fact that dst_ptr and a_ptr are equal. I'm pretty sure I can get this approach to work, however, I'm not...

...My first attempt at solving this problem did something similar to > what is done in JumpThreadingPass::ProcessImpliedCondition(). > Specifically, it tried to prove that dst_ptr was non-null based on > a dominating condition. The only tricky parts were to deal with > hammocks/diamonds when walking up the CFG (See: > https://reviews.llvm.org/D36287 <https://reviews.llvm.org/D36287> > as a concrete example of how I proposed to get an immediate > dominator without the domtree) and to account for the fact that > dst_ptr and a_ptr are equal....

Hi Dave, >> We generate xEXT nodes in many cases. Unlike GCC which vectorizes >> inner loops, we vectorize the implicit outermost loop of data-parallel >> workloads (also called whole function vectorization). We vectorize >> code even if the user uses xEXT instructions, uses mixed types, etc. >> We choose a vectorization factor which is likely to generate more

...similar to what is done in > JumpThreadingPass::ProcessImpliedCondition(). > Specifically, it tried to prove that dst_ptr was > non-null based on a dominating condition. The only > tricky parts were to deal with hammocks/diamonds when > walking up the CFG (See: > https://reviews.llvm.org/D36287 > <https://reviews.llvm.org/D36287> as a concrete > example of how I proposed to get an immediate > dominator without the d...