similar to: Removing IPConstantPropagation.cpp

Should ConstantProp.cpp also be removed? It doesn't look like it's been worked on in over 10 years, and aside from check-llvm lit tests, the only use is in llvm/unittests/ExecutionEngine/MCJIT/MCJITAPITest.cpp via LLVMAddConstantPropagationPass. (it hasn't been ported to the new pass manager which is why I'm asking) On Mon, Jul 27, 2020 at 6:01 PM Chris Lattner via llvm-dev <

Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> writes: > No tests fail with the patch below, so I would say it's pretty useless. It > seems that the C bindings are the only user but we can probably just have them > return IPSCCP instead. I don't necessarily think your conclusion is wrong, but the patch isn't proving what you think it's proving. In fact, the

On 7/14/20 4:34 PM, Hal Finkel via llvm-dev wrote: > > On 7/14/20 11:28 AM, Fangqing Du wrote: >> Thank you Hal and Stefan! >> >> Bug report is filed: https://bugs.llvm.org/show_bug.cgi?id=46717 >> <https://bugs.llvm.org/show_bug.cgi?id=46717> >> >> And Stefan, >> I think 'attributor' is a really nice pass, and can infer more >>

The pass is pretty rudimental (as the comment at the top of the file hints), and it seems LLVM already has IPSCCP (which should do a better job at interprocedural constant propagation). I'm also not entirely sure it's used anywhere. Is there any reason to keep it around? Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" --

Which transformation passes are 'safe', meaning it does not worsens the effectiveness of a later pass or the generated code? I imagine all passes which either removes data or add attributes are included in this list, plus some simplification passes: -adce -argpromotion -constmerge -constprop -deadargelim -dse -functionattrs -globaldce -globalopt -gvn -instcombine -internalize

On Mon, Jan 30, 2017 at 9:34 AM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > We need to disable most forms of IPO on naked functions. We already do this > in DeadArgElimination.cpp. We need to do it in more places. > +1. Carlo, can you please open a bug? -- Davide "There are no solved problems; there are only problems that are more or less solved"

On 2017-01-30 18:41, Davide Italiano wrote: > On Mon, Jan 30, 2017 at 9:34 AM, Reid Kleckner via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> We need to disable most forms of IPO on naked functions. We already do this >> in DeadArgElimination.cpp. We need to do it in more places. >> > > +1. Carlo, can you please open a bug? > Done

I fell over this issue yesterday myself with lots of asserts being thrown. I think the issue is in lib/IR/AsmWriter.cpp:1618 in the function AssemblyWriter::printFunction(const Function *F) Looking at the code I think the 2nd for loop should be preceded by the test ... if (Idx < AS.getNumSlots()) Not sure why it doesn't fail on other platforms as it looks like it should be a genuine

Hi, > I think the IR in both of your examples makes things harder for the compiler than expected from the original C source. Note that both versions are from clang with -O2. The first is with version 9.0 and the second is with the trunk. > but in the branch only %0 is used. Sinking the lshr too early made the analysis harder. Yes, exactly! That's what I figured too. > The version

Interesting that we're getting a relative flood of these recently. See here: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131346.html I don't think one can reliably get a Function analysis pass from within a ModulePass using the legacy pass manager. You have to manually construct the pass yourself. -David Jonathan Smith via llvm-dev <llvm-dev at

Hi John, I hadn't seen alive2, amazing program, thank you! Keep up the good work. > I'm not sure that I've captured what you mean here To be more specific for everyone: - First of all, I hope it's clear that in the original (C) code, the region - 0x8 > 1000 branch should be eliminated. That is because it is inside a block that has ensured that 8 < region < 12. But

Hi, I'm trying to autotune a good sequence of IR optimization passes and I seem to run into segfaults in opt (in LLVM5) with certain pass orderings. Is this expected behavior? If so, what would be the recommended way of determining pass dependencies so that I can encode them into the tuner? The test program can be found here: https://gist.github.com/kavon/92d153cdd54ce9b77162af3af47d4c95

Hi all, Let's see an example (from Alexandre Isoard) first: **************************************************************************************** ; RUN: opt -ipsccp -deadargelim -licm -O2 -S < %s @g = internal global i32 0 ; Function Attrs: argmemonly define internal void @foo(i32* nonnull dereferenceable(4) %arg, i32 %val) #0 { entry: store i32 %val, i32* %arg ret void } define

Thank you Hal and Stefan! Bug report is filed: https://bugs.llvm.org/show_bug.cgi?id=46717 And Stefan, I think 'attributor' is a really nice pass, and can infer more precise and useful attributes, which may give more opportunities for optimization. But we shouldn't depend on 'attributor' to correct wrong function attributes, because we cannot run 'attributor' after

Hi, I check-out the latest version of LLVM and see many failures (on Win64): ******************** 67> FAIL: LLVM :: Transforms/GlobalOpt/zeroinitializer-gep-load.ll (5518 of 7763) 67> ******************** TEST 'LLVM :: Transforms/GlobalOpt/zeroinitializer-gep-load.ll' FAILED ******************** 67> Script: 67> -- 67> W:/LLVM_org/build64/bin/Debug/opt.EXE <

Hi, I used the following commands on the program attached below: llvm-gcc --emit-llvm main.c -c -o main.bc opt -ipconstprop main.bc -o main1.bc diff main.bc main1.bc no difference was o/p :( The Program Segment is as shown below: #include <stdio.h> void f1(int a) { a=a+1; printf("%d",a); } void f2() { int b; b=1; f1(b); } int main() { int

Chris Lattner wrote: > On Tue, 9 May 2006, Nick Lewycky wrote: > >> For an analysis pass, I'm interested in reading the lattice values >> calculated by SCCP. Should I split the current SCCP optimization into an >> analysis piece and the optimization that depends on it, so that I can >> use its analysis results? > > SCCP is already split into an SCCPSolver

Hi, On Sat, Sep 5, 2009 at 9:12 PM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote: > Is the patch below ok? > > Index: LLVMCConfigurationEmitter.cpp > =================================================================== > --- LLVMCConfigurationEmitter.cpp    (revision 80668) > +++ LLVMCConfigurationEmitter.cpp    (working copy) > @@ -1141,6 +1141,7 @@ >          

Hello all, LangRef isn't clear about the value of padding when an aggregate value is stored into memory, and I'd like to suggest that storing an aggregate fills padding with undef. Here are a few clues that supports this change: - According to C17, the value of padding bytes when storing values in structures or unions is unspecified. - IPSCCP ignores padding and directly stores a

Hello, I have a problem shutting down a domU with xen-4.1.2, which doesn''t terminate the corresponding blktap2 process, since one (other) VM uses a image file, which contains spaces in its file name. /var/log/xen/xend-debug.log has the following information: Unhandled exception in thread started by Traceback (most recent call last): File