Displaying 20 results from an estimated 300 matches similar to: "[LLVMdev] Help getting condition of branch instructions in pass"
2018 Aug 30
4
crash problem when using IndirectBrInst to replace BranchInst
Hello all,
I have written a pass, which replaces condition branchinst using
indirectBr to obfuscate program.
The origin IR is as the following:
br i1 %1, label %2, label %3
And the transformed IR is as the follwoing:
%4 = select i1 %1, i8* blockaddress(@func, %2), i8* blockaddress(@func,
%3)
indirectbr i8* %4, [label %2, label %3]
The pass's core function is as the
2018 Aug 31
2
crash problem when using IndirectBrInst to replace BranchInst
With Debug mode, it shows the assert error:
Assertion failed: (I != BlockLiveness.end() && "Predecessor not found"),
function calculateLocalLiveness, file lib/CodeGen/StackColoring.cpp, line
782.
1. <eof> parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module
'busybox/archival/libarchive/decompress_bunzip2.c'.
4. Running
2012 Sep 26
9
[LLVMdev] [PATCH / PROPOSAL] bitcode encoding that is ~15% smaller for large bitcode files...
Hi all,
I've been looking into how to make llvm bitcode files smaller. There is
one simple change that appears to shrink linked bitcode files by about 15%.
See this spreadsheet for some rough data:
https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E
The change is in how operand ids are encoded in bitcode files. Rather than
use an "absolute
2012 Sep 26
0
[LLVMdev] [PATCH / PROPOSAL] bitcode encoding that is ~15% smaller for large bitcode files...
Hi Jan,
> I've been looking into how to make llvm bitcode files smaller. There is one
> simple change that appears to shrink linked bitcode files by about 15%. See
> this spreadsheet for some rough data:
>
> https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E
the improvement is wonderful!
...
> In any case, the patch is attached if
2012 Feb 08
2
[LLVMdev] BackedgeTakenCount calculation for fortran loops and DragonEgg gfortran-4.6
Hello, I'm finding problems with BackEdgeTaken count calculation in
even simple fortran loops with gfortran-4.6 + DragonEgg 3.0.
Even for simple double loops like this one:
program test2
integer i,j,k
dimension k(100,100)
do j=1,100
do i=1,100
k(i,j) = i
enddo
enddo
write(*,*) k(1,30)
end
make the ScalarEvolution
2012 Feb 08
2
[LLVMdev] BackedgeTakenCount calculation for fortran loops and DragonEgg gfortran-4.6
Attached
2012/2/8 Marcello Maggioni <hayarms at gmail.com>:
> Mmm, sorry, the patch I posted crashes if ExitBr is null (which it may
> be ...) , this one should be ok (and passess all the ScalarEvolution
> tests in LLVM):
>
> diff --git a/lib/Analysis/ScalarEvolution.cpp b/lib/Analysis/ScalarEvolution.cpp
> index daf7742..b10fab2 100644
> ---
2012 Feb 08
2
[LLVMdev] BackedgeTakenCount calculation for fortran loops and DragonEgg gfortran-4.6
Well, it wasn't intended as a "real" patch to be included , but more
as a "proof of concept" for a solution. Do you think it is a valid
solution and I'm correct in my assumption? If so then I'll clean up
the patch and attach a testcase for inclusion.
Thanks!
Marcello
2012/2/9 Nick Lewycky <nlewycky at google.com>:
> Your patch should include a testcase,
2012 Feb 09
2
[LLVMdev] BackedgeTakenCount calculation for fortran loops and DragonEgg gfortran-4.6
This is the .ll for that graph (attached). I think I understand what
you are saying.
This particular testcase returns CNC not because the exit block
doesn't have a unique predecessor, but because the unique predecessor
(the inner loop block) has a successor that is inside the loop (in
this case itself, because it's the inner loop block).
That doesn't change, anyway, the assuption that
2012 Feb 08
0
[LLVMdev] BackedgeTakenCount calculation for fortran loops and DragonEgg gfortran-4.6
Mmm, sorry, the patch I posted crashes if ExitBr is null (which it may
be ...) , this one should be ok (and passess all the ScalarEvolution
tests in LLVM):
diff --git a/lib/Analysis/ScalarEvolution.cpp b/lib/Analysis/ScalarEvolution.cpp
index daf7742..b10fab2 100644
--- a/lib/Analysis/ScalarEvolution.cpp
+++ b/lib/Analysis/ScalarEvolution.cpp
@@ -4293,9 +4293,15 @@
2012 Feb 08
0
[LLVMdev] BackedgeTakenCount calculation for fortran loops and DragonEgg gfortran-4.6
Your patch should include a testcase, see test/Analysis/ScalarEvolution for
examples. "BranchInst* " should be "BranchInst *". You should have spaces
after the // in your comments. One of the comment lines isn't indented
properly.
Nick
On 8 February 2012 12:05, Marcello Maggioni <hayarms at gmail.com> wrote:
> Attached
>
> 2012/2/8 Marcello Maggioni
2012 Feb 08
0
[LLVMdev] BackedgeTakenCount calculation for fortran loops and DragonEgg gfortran-4.6
On 8 February 2012 15:50, Marcello Maggioni <hayarms at gmail.com> wrote:
> Well, it wasn't intended as a "real" patch to be included , but more
> as a "proof of concept" for a solution. Do you think it is a valid
> solution and I'm correct in my assumption? If so then I'll clean up
> the patch and attach a testcase for inclusion.
>
I'm
2012 Feb 09
0
[LLVMdev] BackedgeTakenCount calculation for fortran loops and DragonEgg gfortran-4.6
This is instead a very simple (handmade) test case that triggers the
problem (attached)
Also a more conforming patch has been attached
2012/2/9 Marcello Maggioni <hayarms at gmail.com>:
> This is the .ll for that graph (attached). I think I understand what
> you are saying.
> This particular testcase returns CNC not because the exit block
> doesn't have a unique predecessor,
2012 Feb 09
1
[LLVMdev] BackedgeTakenCount calculation for fortran loops and DragonEgg gfortran-4.6
FInally I had the time to complete everything up. Now I included the
test case in the patch and the testcase runs with the LLVM tests
system.
2012/2/9 Marcello Maggioni <hayarms at gmail.com>:
> This is instead a very simple (handmade) test case that triggers the
> problem (attached)
> Also a more conforming patch has been attached
>
> 2012/2/9 Marcello Maggioni <hayarms
2012 May 21
2
[LLVMdev] VMKit build broken
Hi,
I just thought of trying vmkit and checked out the source
from the svn repo a few minutes back. The build is failing with the
following error.
llvm[4]: Compiling CGCleanup.cpp for Release+Asserts build
CGCleanup.cpp:507:36: error: no member named 'getCaseSuccessor' in
'llvm::SwitchInst'; did you mean 'getSuccessor'?
2020 Mar 09
3
RFC: Making a common successor/predecessor interface
Hi,
As part of an ongoing work to extend the GraphDiff (this models a CFG
view), I came across the need to have a common interface for accessing
successors/predecessors in various IR units, such that a type such as
`typename NodeT::succ_iterator` could be used in templated code.
In particular, the need arose for BasicBlocks, MachineBasicBlocks,
VPBlockBase and clang::CFGBlock.
The least invasive
2006 Jul 04
2
[LLVMdev] Critical edges
On Tue, 4 Jul 2006, Fernando Magno Quintao Pereira wrote:
> However, it does not remove all the critical edges. I am getting a very
> weird dataflow graph (even without the Break Critical edges pass). The
> dataflow generated by MachineFunction::dump() for the program below is
> given here:
> http://compilers.cs.ucla.edu/fernando/projects/soc/images/loop_no_crit2.pdf
...
> The
2020 Mar 10
4
RFC: Making a common successor/predecessor interface
Hi Dave,
It may be possible to do this with the current API, but what I was looking
for is a common API for existing block types. For example there is no
succ_begin for Machine BasicBlock.
I'm looking to make the CFGSuccessors and CFGPredecessors classes in
CFGDiff.h templated, and this needs a common API for all types
instantiations.
Does this clarify your question or did I misunderstand
2018 May 24
0
LLVM Pass To Remove Dead Code In A Basic Block
> On 25 May 2018, at 01:46, Aaron via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> LLVM optimization pass gives an error "Terminator found in the middle of a basic block!" since basic block IR may have multiple "ret" instructions. It seems LLVM does not accept multiple return in a basic block by default.
>
Yes, if you’re inserting
2018 May 24
2
LLVM Pass To Remove Dead Code In A Basic Block
Hi all,
LLVM optimization pass gives an error "Terminator found in the middle of a
basic block!" since basic block IR may have multiple "ret" instructions. It
seems LLVM does not accept multiple return in a basic block by default.
Is there a specific optimization or pass that I can enable to remove
unreachable codes in basic blocks?
Best,
Aaron
-------------- next part
2013 Jul 31
1
[LLVMdev] Problem to remove successors
Hi All,
I need to remove successors from every basic block to insert new ones
I tried this code, but it doesn't work
void RemoveSuccessor(TerminatorInst *TI, unsigned SuccNum) {
assert(SuccNum < TI->getNumSuccessors() &&
"Trying to remove a nonexistant successor!");
// If our old successor block contains any PHI nodes, remove the entry
in the
//