Displaying 20 results from an estimated 1000 matches similar to: "CodeExtractor buggy?"
2008 Nov 17
1
[LLVMdev] Question about ExtractLoop
Hi,
I have a question about ExtractLoop() in CodeExtractor.cpp.
The sample code is a simple list traversal, as attached. The generated
bitcode (from llvm-gcc -O1) is shown below.
--------------------------------------------------------------------------------------------------------------------------------
define i32 @walk(%struct.node2* %list2) nounwind {
entry:
%0 = icmp eq
2011 Jan 25
2
[LLVMdev] Update PHINode after extracting code
Hi all,
I have problem with ExtractCodeRegion (CodeExtractor.cpp).
My original program is as follows.
bb:
...
%tmp.15 = load %struct.MYSQL_ROWS** %3, align 4
...
bb1:
...
%tmp.1 = load %struct.MYSQL_ROWS** %6, align 4
...
bb4: ; preds = %bb1, %bb,
%entry
%tmp.0 = phi %struct.MYSQL_ROWS* [ null, %entry ], [ %tmp.15, %bb ], [
%tmp.1, %bb1 ]
2013 Oct 25
3
[LLVMdev] Question About Function Cloning
Hello all;
I have been writing this LLVM pass that extracts loops in a function
and then duplicates the function so the loop is executed twice. The
pass executes fine but the produced bit code does not behave correctly
as it should (both the original and duplicated function in which the
loop is extracted is called, but from the output it seems only one of
them is executed.)
Here is the source:
2011 Jan 27
0
[LLVMdev] Update PHINode after extracting code
I guess I didn't have a clear question.
Suppose we have BB1 and BB2 both point to BB3.
BB1 has variable x. BB2 also as variable x.
BB3 will have PHINode for x with 2 value from BB1 and BB2.
BB1 BB2
\ /
BB3
Now if BB1 and BB2 is extracted into a function
(using ExtractCodeRegion), they will be replaced by
a basic block called codeRepl (which has a call to the extracted
2012 Nov 14
0
[LLVMdev] CodeExtractor doesn't work with debugging metadata
Hi,
I've been experimenting with the CodeExtractor class and have been running into a problem where the verifier pass fails with the error "function-local metadata used in wrong function" when I compile with debugging symbols enabled (-g flag). The issue seems to be that after extraction we have metadata that references variables that aren't allocated in the extracted function.
2011 Jan 27
2
[LLVMdev] Update PHINode after extracting code
On 01/26/2011 07:50 PM, Vu Le wrote:
> I guess I didn't have a clear question.
>
> Suppose we have BB1 and BB2 both point to BB3.
> BB1 has variable x. BB2 also as variable x.
> BB3 will have PHINode for x with 2 value from BB1 and BB2.
> BB1 BB2
> \ /
> BB3
>
> Now if BB1 and BB2 is extracted into a function
> (using ExtractCodeRegion), they
2007 Dec 19
0
[LLVMdev] JIT Stub Problem
I'm having an issue with the Stubs used by the JIT Compiler. I'm not sure if it's a bug or if I'm doing something incorrectly.
I've got a long complicated function with the following basic blocks at the end of it (The complete .ll file is attached):
falseBlock: ; preds = %__exp.exit340
ret int 617
codeRepl: ; preds = %__exp.exit340
2013 Feb 03
2
[LLVMdev] [Polly] Parallelizing outer loop containing inner reduction loop
Oops, sorry for the message title, making it more descriptive now...
2013/2/3 Dmitry Mikushin <dmitry at kernelgen.org>
> Dear all,
>
> Yesterday, from the customer's code I observed relatively simple case,
> where Polly is unable to detect parallelizable outer loop. Consider two
> versions of Fortran routine:
>
> 1)
>
> subroutine filter(H, szh, X, szx, Y,
2010 Jan 09
0
[LLVMdev] [PATCH] Fix nondeterministic behaviour in the CodeExtractor
On Jan 8, 2010, at 5:01 PM, Julien Lerouge wrote:
> Hello,
>
> The CodeExtractor contains a std::set<BasicBlock*> to keep track of
> the
> blocks to extract. Iterators on this set are not deterministic, and so
> the functions that are generated are not (the order of the
> inputs/outputs can change).
>
> The attached patch uses a SetVector instead. Ok to apply ?
2010 Jan 09
2
[LLVMdev] [PATCH] Fix nondeterministic behaviour in the CodeExtractor
Hello,
The CodeExtractor contains a std::set<BasicBlock*> to keep track of the
blocks to extract. Iterators on this set are not deterministic, and so
the functions that are generated are not (the order of the
inputs/outputs can change).
The attached patch uses a SetVector instead. Ok to apply ?
Thanks,
Julien
--
Julien Lerouge
PGP Key Id: 0xB1964A62
PGP Fingerprint: 392D 4BAD DB8B CE7F
2014 Dec 08
3
[LLVMdev] Incorrect loop optimization when building the Linux kernel
I was trying to build the Linux kernel with clang and observed a crash due to incorrect loop optimization:
drivers/base/firmware_class.c
extern struct builtin_fw __start_builtin_fw[];
extern struct builtin_fw __end_builtin_fw[];
static bool fw_get_builtin_firmware(struct firmware *fw, const char *name)
{
struct builtin_fw *b_fw;
for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw;
2010 Dec 31
3
[LLVMdev] CodeExtractor.cpp potential bug?
There might be a misuse of DominatorTree::splitBasicBlock in
CodeExtractor.cpp, line 145.
Header is splited into two (OldPred->NewBB).
Line 145 updates the dominator tree by calling DT->splitBasicBlock(NewBB).
I think it should be DT->splitBasicBlock(OldPred).
When I tried to extract a code region whose header has 2 successors, my pass
crashed.
It was because header (or OldPred) is the
2008 Nov 19
2
[LLVMdev] Problem in CodeExtractor::severSplitPHINodes()
Hi,
I found a problem in CodeExtractor::severSplitPHINodes()
<CodeExtractor.cpp>.
The algorithm first separates the header block into two, one containing only
PHI nodes and the other containing the remaining non-PHI nodes. The variable
NewBB holds the pointer to the latter half block. Later, it tries to update
DT information.
if (DT)
DT->splitBlock(NewBB);
In splitBlock, it checks
2011 Jan 03
0
[LLVMdev] CodeExtractor.cpp potential bug?
On Dec 31, 2010, at 11:20 AM, Vu Le wrote:
> There might be a misuse of DominatorTree::splitBasicBlock in CodeExtractor.cpp, line 145.
> Header is splited into two (OldPred->NewBB).
>
> Line 145 updates the dominator tree by calling DT->splitBasicBlock(NewBB).
> I think it should be DT->splitBasicBlock(OldPred).
>
> When I tried to extract a code region whose
2015 Jul 16
2
[LLVMdev] Improving loop vectorizer support for loops with a volatile iteration variable
----- Original Message -----
> From: "Chandler Carruth" <chandlerc at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Hyojin Sung" <hsung at us.ibm.com>, llvmdev at cs.uiuc.edu
> Sent: Thursday, July 16, 2015 1:06:03 AM
> Subject: Re: [LLVMdev] Improving loop vectorizer support for loops
> with a volatile iteration
2013 Nov 18
2
[LLVMdev] CodeExtractor status?
I am working on a pass to extract small regions of code to run somewhere else (different node in a cluster). Basically what I need is the ability to isolate a region of code, get its inputs and outputs, create a new function with the extracted code and code aggregating the in and out parameters as structs that can be cast for a “void*”-based interface.
It looks like the CodeExtractor
2012 May 02
1
[LLVMdev] Taking over work on CodeExtractor, spiffing it up, and making it nice & easy to use
On Wed, May 2, 2012 at 1:57 AM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote:
> At KernelGen we have an out-of-tree variation of CodeExractor called
> BranchedCodeExractor [1], which instead of taking a code region into a new
> function, does it conditionally:
>
OK... as this is an out-of-tree branch of the code extraction, nothing I'm
planning should negatively impact
2015 Jul 16
2
[LLVMdev] Improving loop vectorizer support for loops with a volatile iteration variable
----- Original Message -----
> From: "Chandler Carruth" <chandlerc at google.com>
> To: "Hyojin Sung" <hsung at us.ibm.com>, llvmdev at cs.uiuc.edu
> Sent: Wednesday, July 15, 2015 7:34:54 PM
> Subject: Re: [LLVMdev] Improving loop vectorizer support for loops
> with a volatile iteration variable
> On Wed, Jul 15, 2015 at 12:55 PM Hyojin Sung
2008 Nov 20
0
[LLVMdev] Problem in CodeExtractor::severSplitPHINodes()
On Nov 19, 2008, at 7:41 AM, Jack Tzu-Han Hung wrote:
> Hi,
>
> I found a problem in CodeExtractor::severSplitPHINodes()
> <CodeExtractor.cpp>.
>
> The algorithm first separates the header block into two, one
> containing only PHI nodes and the other containing the remaining non-
> PHI nodes. The variable NewBB holds the pointer to the latter half
> block.
2013 Nov 25
0
[LLVMdev] CodeExtractor status?
Hi Brandon,
> Did you have issues with the Verifier complaining about function-local
> metadata after moving blocks? Did you find a good solution for this?
>
It looks like you are moving blocks or instructions with attached
metadata to another function. Some metadata is function-specific, so the
verifier complains because the instruction/BB and the metadata don't
belong to the