http://llvm.org/bugs/show_bug.cgi?id=11142
Summary: Testcase: suboptimal code in memory transportation
Product: new-bugs
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
AssignedTo: [email protected]
ReportedBy: [email protected]
CC: [email protected]
Created an attachment (id=7462)
--> (http://llvm.org/bugs/attachment.cgi?id=7462)
test case (line 12-72)
I have attached an example file to show you how i'm doing string concatenation.
(This is the result after opt -O3 from llvm3.0)
There are two strings (a and b) allocated and filled with malloc and
llvm.memcpy (from an internal constant). Then, a third string (c) is created.
The new length is correctly constant folded, and llvm.memcpy copies the memory
from the first two strings into the new one.
If LLVM would change the memcpy from a and b to c to a memcpy from the
(internal constant) a to c, it would be much better optimizable:
- Filling c could be made of one big memcpy
- The data filled into a and b would not longer be used
- So dead code elimination could remove two memcpy calls
- Then no calls are done on a and b, all other store's could be removed by
dead store elimination
- From a and b, a malloc/free pair would be remain which will be removed then
I hope you can implement some optimization rules to achieve that improvement ;)
Explaination of the example:
- The interesting part is from line 12-72
- a is built in line 23
- b is built in line 34
- in line 46 and 48, a copy from a->c and b->c is performed
- target of the optimization should be to have "i8* getelementptr inbounds ([7
x i8]* @label8, i64 0, i64 0)" as src parameter instead of %2 in line 46
- in line 48, it should be "i8* getelementptr inbounds ([7 x i8]* @label8, i64
0, i64 0)" instead of %5
- this would open all doors to completely constant fold the whole function.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
