similar to: [LLVMdev] NoFolder class problem

Hi, Just to report that when I tried to compile some code with a NoFolder given as template arg to my IRBuilder, the compiler complained with: In file included from lang_3-llvm.cxx:33: /usr/lib/llvm-2.8/include/llvm/Support/IRBuilder.h: In member function ‘llvm::Value* llvm::IRBuilder<preserveNames, T, Inserter>::CreateFNeg (llvm::Value*, const llvm::Twine&) [with bool preserveNames =

On Wed, Nov 17, 2010 at 9:26 PM, BernardH <gmane.comp.compilers.llvm.devel at bernard-hugueney.org> wrote: > Should I consider NoFolder unsupported ? Seeing as it's completely broken (it doesn't insert the created instructions into the relevant basic block) that's probably best... :( (It's also missing most of the casting operations, by the way)

On Wed, Nov 17, 2010 at 9:37 PM, Frits van Bommel <fvbommel at gmail.com> wrote: > On Wed, Nov 17, 2010 at 9:26 PM, BernardH > <gmane.comp.compilers.llvm.devel at bernard-hugueney.org> wrote: >> Should I consider NoFolder unsupported ? > > Seeing as it's completely broken (it doesn't insert the created > instructions into the relevant basic block)

IRBuilder is a templated class, and one of the template arguments is the constant folder to use. By default it uses the ConstantFolder class which does target-independant constant folding. If you want to disable constant folding you can specify the NoFolder class instead, i.e. declare the builder as follows: IRBuilder<true, llvm::NoFolder> builder(body) On 26 Nov 2013, at 19:23, Daniel

Hello, I am create a <3 x i32> vector in LLVM IR. Then I insert 3 instructions and later on I try to load one instruction from the vector. The insertion seems to work, however, when I try to load a specific instruction from a vector I seems that it does not work. This is the part of my IR: %"ins or1" = insertelement <3 x i32> undef, i32 %38, i32 0 %"ins and2"

On Thu, Apr 15, 2010 at 3:40 AM, Artur Pietrek <pietreka at gmail.com> wrote: > Hi all > Ups, I'm really sorry for that previous message, I've sent it by mistake. > > So let me write it once more. > > I've been working for some time now on a backend for our CPU. However I > couldn't figure out how to implement some stuff. > I'd appreciate your help

Hi all, While implementing debug info for our backend, we've noticed a problem with debug_line section. We believe that the following code is wrong: // DW_AT_stmt_list is a offset of line number information for this // compile unit in debug_line section. It is always zero when only one // compile unit is emitted in one object file. addUInt(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_data4,

I updated DwarfDebug to use section offset, instead of hard coding 0, to handle LTO properly. r107202. Thanks for brining this up. - Devang On Tue, Jun 29, 2010 at 11:27 AM, Devang Patel <devang.patel at gmail.com> wrote: > DW_AT_stmt_list attribute's value is a section offset to the line no > info for current compilation unit. If there is only one  compilation > unit

On Fri, Aug 21, 2009 at 12:33 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Fri, Aug 21, 2009 at 2:02 AM, Artur Pietrek<pietreka at gmail.com> wrote: > > Hi All, > > Since few days I observe weird change. > > Consider the following C code > > > > char array[] = "0123456789"; > > extern int test(char arr[], int size); > >

Hi. Thanks. I changed the code but the problem exists. This is my new code which is again very simple: ... bool runOnFunction(Function &F) override { vector<Instruction *> dels; dels.clear(); for (inst_iterator It = inst_begin(&F), Ie = inst_end(&F); It != Ie;) { Instruction *I = &*(It++); if (auto* op = dyn_cast<BinaryOperator>(I)) { IRBuilder<NoFolder>

Hi All, Since few days I observe weird change. Consider the following C code char array[] = "0123456789"; extern int test(char arr[], int size); int main(void) { return test(array-1, sizeof(array)-1); } using clang frontend i get this: %call = call i32 @test(i8* getelementptr inbounds ([11 x i8]* @array, i32 0, i32 -1), i32 10) ; <i32> [#uses=1] and using LLVM-GCC this: %1 =

Hi Andrew, thanks for answering On Thu, Apr 15, 2010 at 3:35 PM, Andrew Lenharth <andrewl at lenharth.org>wrote: > On Thu, Apr 15, 2010 at 3:40 AM, Artur Pietrek <pietreka at gmail.com> wrote: > > Hi all > > Ups, I'm really sorry for that previous message, I've sent it by mistake. > > > > So let me write it once more. > > > > I've

Hello, using the LLVM API, I've build one very simple function that adds two ConstantInts and returns the result. I noticed that, when I emit IR code, it is optimized to a simple "ret i16 42" when I add 40 and 2. I'd like to see the operations that are necessary to compute the result, though. Can I somehow disable this optimization in the pass, leading to more verbose IR code?

LLVM is built in Release mode. The version is 6.0.0. I think that a similar code worked on verison 3.9.0. It is probably a null pointer dereference occurring in eraseFromParent(). I checked and reconfirmed that the instruction had no uses. Perhaps I should rebuild LLVM. Thanks. On Wed, Aug 8, 2018 at 9:03 PM, mayuyu.io <admin at mayuyu.io> wrote: > Hmmmm that’s strange. Do you get an

On 11/23/2011 05:52 PM, Hal Finkel wrote: > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: >>> > > Tobias, >>> > > >>> > > I've attached an updated patch. It contains a few bug fixes and many >>> > > (refactoring and coding-convention) changes inspired

On 12/02/2011 06:32 PM, Hal Finkel wrote: > On Fri, 2011-12-02 at 17:07 +0100, Tobias Grosser wrote: >> On 11/23/2011 05:52 PM, Hal Finkel wrote: >>> On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: >>>>> On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: >>>>>> > Tobias, >>>>>> > >>>>>>

DW_AT_stmt_list attribute's value is a section offset to the line no info for current compilation unit. If there is only one compilation unit generated per .o file then it is always zero. What kind of errors are you seeing ? - Devang On Tue, Jun 29, 2010 at 9:02 AM, Artur Pietrek <pietreka at gmail.com> wrote: > Hi all, > While implementing debug info for our backend, we've

Hi Devang, Thanks for working on that. Unfortunately after your change it still doesn't work (I've tried x86 and our backend under Linux). The problem is that you put difference between two labels .Lset7 = .Lsection_line_begin-.Lsection_line ## DW_AT_stmt_list and that will be evaluated by assembler to a constant. It has to be a label, not a constant, because it is the linker who knows

Hola LLVMers, I was curious about the state of stack alignment on x86. I noticed there are a few bugs outstanding on the issue. I recently added some code which had the effect of throwing an extra function parameter on our stack at runtime, a 4 byte pointer. Esp is now not 16-byte aligned, so instructions like unpcklps xmm1, dword ptr [eps] cause grief. My AllocaInstr instructions are

Hi Michael, +llvmdev,Hal,Nadav For testing, I was currently thinking of a two pronged approach. Lit tests as you suggest with a dummy pass, probably with command line options to define what transform to do, and unit tests to test the delegate behaviour and return values. I'll try and produce a mega patch with at least the loop vectoriser moved over, then split it up again after review.