similar to: [LLVMdev] warning from -instcombine

On Feb 27, 2009, at 1:47 AM, Jay Foad wrote: > Hi, > > I noticed this code in lib/Transforms/Scalar/InstructionCombining.cpp: > > cerr << "WARNING: While resolving call to function '" > << Callee->getName() << "' arguments were dropped!\n"; > > If you're using LLVM as a static compiler, this warning is a

On Feb 27, 2009, at 10:37 AM, Evan Cheng wrote: > > On Feb 27, 2009, at 1:47 AM, Jay Foad wrote: > >> Hi, >> >> I noticed this code in lib/Transforms/Scalar/ >> InstructionCombining.cpp: >> >> cerr << "WARNING: While resolving call to function '" >> << Callee->getName() << "' arguments

On 2009-02-27 21:33, Chris Lattner wrote: > On Feb 27, 2009, at 10:50 AM, Devang Patel wrote: > > >>>> So should it be removed, or downgraded to DOUT, or something? >>>> >>> We should not remove them. These indicate a bug in the source, >>> frontend, or earlier optimization passes. It's pretty useful. >>> >>

> How about setting an error flag, and error message in the Module, then > let the caller know the Module is broken? I'm not sure what you mean by "broken". In the case of this "arguments were dropped" warning, the module just contains some code that will give undefined behaviour if it gets executed. It would be reasonable for an optimiser to turn that code into a

On Fri, Feb 27, 2009 at 4:50 PM, Aaron Gray <aaronngray.lists at googlemail.com > wrote: > On Fri, Feb 27, 2009 at 4:32 PM, Jay Foad <jay.foad at gmail.com> wrote: > >> >> Could you please rig Makefile.rules or something to print out the value >> >> of $(LLVM_ON_WIN32) ? The only way I can think of this happening is if >> >> that's

On Fri, Feb 27, 2009 at 4:32 PM, Jay Foad <jay.foad at gmail.com> wrote: > >> Could you please rig Makefile.rules or something to print out the value > >> of $(LLVM_ON_WIN32) ? The only way I can think of this happening is if > >> that's erroneously false. > > This works for me: > > Index: Makefile.rules >

Hi Andy, Thanks for the explanations. Yes AMDGPU is in-order and has MicroOpBufferSize = 1. Re "issue limited" and instruction groups: could it make sense to disable the generic scheduler's detection of issue limitation on in-order CPUs, or on CPUs that don't define instruction groups, or some similar condition? Something like: --- a/lib/CodeGen/MachineScheduler.cpp +++

Hi all, With the newest patches to LLVM, there should be no reason for having "#include <iostream>" in any library source code file, except for lib/ Support/Streams.cpp. Please use the following instead: OLD NEW --- --- std::ostream llvm::OStream std::istream llvm::IStream std::cerr llvm::cerr std::cerr llvm::cout

> I'm linking a program (my ellsif driver) that basically brings in most > of the LLVM stuff: bitcode reading, optimizations, linking, and target > code generation. > > All of a sudden, I'm getting the following when I run: > [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i test/sieve.i -time-actions > -O5 > <premain>: CommandLine Error: Argument

Hi, I'm trying to understand why MachineScheduler does a poor job in straight line code in cases like the one in the attached debug dump. This is on AMDGPU, an in-order target, and the problem is that the IMAGE_SAMPLE instructions have very high (80 cycle) latency, but in the resulting schedule they are often placed right next to their uses like this: 1784B %140:vgpr_32 =

Hi, I am trying to compile the Hello World pass (described at http://llvm.org/docs/WritingAnLLVMPass.html#basiccode) in an LLVM Project and I get an error, 'no match for ‘operator<<’ at line llvm::cerr << "*Hello: *" << F.getName() << "\n"; But when I looked up in the LLVM API Documentation, I think "<<" operator is not overloaded

Hi, I've been upgrading some custom LLVM passes to work with LLVM 2.6 instead of LLVM 2.5. I've noticed that in 2.6, some functions seem to have several local values with no name (where getName() returns an empty string). I never saw this in 2.5. Is this a known change in behaviour? Is there some handy way to get unique, deterministic names assigned to all values in a function? Thanks,

Hello, I have a couple of doubts, as listed below: 1. To list all the global variables in the module, I am iterating using type_iterator and for each Type I get, I am using value_iterator to iterate over Values . In the second iteration I am getting unexpected results. For each type obtained from type_iterator->second, value_iterator->first produces the same list as what

Hi all, I am trying to write a pass where i am creating a clone of a function (the only difference being, the new function returns void , instead of any value). I am creating a new Function Type with a void return type (rest being the same as original function), and using this i am creating a new function body. Then, i clone the body of the old function into new function, but when ever i

On Tuesday 04 August 2009 18:24, Chris Lattner wrote: > The big issue is things like this: > > DOUT << foo.getName() << "\n"; > > When -debug is disable and even when assertions are turned off, > foo.getName() is still called. When you use: Yep, that's a problem. > DEBUG(errs() << foo.getName() << "\n"); > > When

Hi, I'm gonna try to give some feedback, but I have only been working with LLVM for a few days, so don't take what I'm saying without verifying :-) > BasicBlock *ProgSlicer::CloneBasicBlock(const BasicBlock *BB, > DenseMap<const Value*, Value*> &ValueMap, > const char *NameSuffix, Function *F) { > > BasicBlock

On Tuesday 04 August 2009 17:52, Chris Lattner wrote: > I'd prefer for it to be eliminated, but it is currently used widely. > If your patches don't make it substantially worse, I won't have a > problem with them. Bonus points for removing DOUTs though :) Ok, this is good to know. With some of these patches I will have opportunities to remove DOUTS. What's the

1. If we run a few passes in a sequence ..is the bytecode file transformed after each pass in sequence i.e if we have a) opt -pass1 -pass2 -pass3 < in.bc > out.bc b)opt -pass1 -pass2 < in.bc > tmp.bc opt -pass3 < tmp.bc > out.bc are the above two equivalent ? what I basically want is to run my pass on an optimised bytecode , so should i optimize it and get a new bytecode

I'm linking a program (my ellsif driver) that basically brings in most of the LLVM stuff: bitcode reading, optimizations, linking, and target code generation. All of a sudden, I'm getting the following when I run: [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i test/sieve.i -time-actions -O5 <premain>: CommandLine Error: Argument 'machine-licm' defined more than once!

On Aug 4, 2009, at 4:03 PM, David Greene wrote: > On Tuesday 04 August 2009 17:52, Chris Lattner wrote: > >> I'd prefer for it to be eliminated, but it is currently used widely. >> If your patches don't make it substantially worse, I won't have a >> problem with them. Bonus points for removing DOUTs though :) > > Ok, this is good to know. With some of