similar to: getting the value back from metadata

Is it just an optimization pass? Maybe I can cancel it somehow with a flag or by doing some code editing? Can you point me to which passes may do that? I'm working on editing a backend that can't work with anything larger than 32 bits. Does the legalize stage work on IR code? Maybe i can use that? On Jan 29, 2015 5:41 AM, Ruiling Song <ruiling.song83 at gmail.com> wrote: LLVM

Hi Duncan, I came across something like the following recently which I guess might be related to your recent work. Any ideas? $ clang++-tot -cc1 crash_on_invalid.cpp -g -emit-obj -fexceptions -fcxx-exceptions crash_on_invalid.cpp:13:1: error: C++ requires a type specifier for all declarations x; ^ 1 error generated. *** Error in `clang++-tot': corrupted double-linked list: 0x000000000754f340

Generally legalize at IR level is not a good idea. But if you need legalization on IR code, you can check PNaCl project. https://chromium.googlesource.com/native_client/pnacl-llvm/ The pass is located at: lib/Transforms/NaCl/ExpandLargeIntegers.cpp You need make some change, as the pass split large integer into 64bit integers. 2015-01-29 16:06 GMT+08:00 Alon Shaltiel (ashaltie) <ashaltie at

Hi all, I'm looking for a way to insert metadata into an instruction/function/basic-block in the IR level, and afterwards reading it in the backend (ARM to be exact). So my questions are: 1. Does/can the metadata in the IR survive the code-generator in some way? 2. Is there a general of 'communication' between the optimizer and the backend? Thanks! Alon

TL;DR: If you use metadata (especially if it's out-of-tree), check the numbered list of lost functionality below to see whether I'm trying to break your compiler permanently. In response to my recent commits (e.g., [1]) that changed API from `MDNode` to `Value`, Eric had a really interesting idea [2] -- split metadata entirely from the `Value` hierarchy, and drop general support for

> On Nov 12, 2014, at 1:00 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > If you don't care about function-local metadata and debug info > intrinsics, skip ahead to the section on assembly syntax in case you > have comments on that. > >> On 2014-Nov-09, at 17:02, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> >>

Hi all, I'm dealing with LLVM's debug information metadata, and have run into an interesting edge case. Under normal circumstances, every `DILocalVariable` has a `User` in the form of the `llvm.dbg.*` intrinsic that produced it. Knowing this, I can go from `DILocalVariable` to `MetadataAsValue`, grab the users, and end up at the corresponding instruction + function. In some cases,

On 11/12/2014 01:00 PM, Duncan P. N. Exon Smith wrote: > If you don't care about function-local metadata and debug info > intrinsics, skip ahead to the section on assembly syntax in case you > have comments on that. > >> On 2014-Nov-09, at 17:02, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> >> 2. No more function-local metadata. >>

> On 2014-Nov-10, at 08:30, Chris Lattner <clattner at apple.com> wrote: > >> On Nov 9, 2014, at 5:02 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> In response to my recent commits (e.g., [1]) that changed API from >> `MDNode` to `Value`, Eric had a really interesting idea [2] -- split >> metadata entirely from the `Value` hierarchy, and

On Wed, Mar 25, 2020 at 8:52 AM Doerfert, Johannes <jdoerfert at anl.gov> wrote: > I think the solution space for the value/use-list issue might be larger > than what was mentioned so far. > > > Some random thoughts: > > If no pass ever walks the use list of a constant, except globals which > we could handle differently, we could get rid of their use-list or >

Hi, I try to use llvm-dis to disassemble the result after opt, my pass will add a intrinsic after the load instruction, like following: bool fpscan::ldAddMetadata (Instruction *Inst, StringRef c) { std::vector<Metadata *> dataTuples; // Add metadata in list dataTuples.push_back(MDString::get(Inst->getContext(), c)); MDNode* N = MDNode::get(Inst->getContext(),

Hello, I am editing the LowerTypeTests pass in LLVM, and part of my additions include the following 3 lines of code: // newTypeName is a std::string MDString* newMD = MDString::get(M.getContext(), newTypeName); ArrayRef<Metadata*> mdArray {ConstantInt::get(Int64Ty, 0), newMD}; auto* node = MDTuple::get(M.getContext(), mdArray); Thus far, I have been developing on a version of Clang with

From: Shaltiel, Alon Sent: Wednesday, November 14, 2012 11:39 AM To: 'llvmdev at cs.uiuc.edu' Subject: Clang error - CPU feature not currently enabled Hello, I'm trying to use clang to compile a file on Mac OS (x86_64) and get the following error. <inline asm>:4:2: error: instruction requires a CPU feature not currently enabled jmp *%edx ^ fatal error: error in

I agree that the ArrayRef is likely the issue. I've debugged a crash caused by a temporary ArrayRef like that a couple times. Either do what David suggested or use a normal array: Metadata *mdArray[] = {ConstantInt::get(Int64Ty, 0), newMD}; ~Craig On Thu, Apr 30, 2020 at 9:56 AM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Apr 30, 2020 at

Most likely candidate for sure. Not a helpful error message though :( -eric On Wed, Nov 14, 2012 at 8:17 AM, Craig Topper <craig.topper at gmail.com>wrote: > I believe it's failing on 64-bit because that's a 32-bit indirect jump. > 64-bit needs jmp *%rdx. > > > On Wednesday, November 14, 2012, Shaltiel, Alon wrote: > >> ** ** >> >> ** **

Hello. I generated in the back end by hand (in C++ code, not with TableGen) some fancy assembly code using Inline ASM expressions and if I use 2 functions in my source code (but NOT just 1 function; I will not present the functions, but each requires me to generate an Inline ASM expression) I get this error at compilation (at scheduling): BB#0: derived from LLVM BB %entry

I believe it's failing on 64-bit because that's a 32-bit indirect jump. 64-bit needs jmp *%rdx. On Wednesday, November 14, 2012, Shaltiel, Alon wrote: > ** ** > > ** ** > > *From:* Shaltiel, Alon > *Sent:* Wednesday, November 14, 2012 11:39 AM > *To:* 'llvmdev at cs.uiuc.edu <javascript:_e({}, 'cvml', > 'llvmdev at cs.uiuc.edu');>'

> On Nov 18, 2019, at 8:33 AM, Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > > Hi llvm-dev@, > > Switching focus to the LLVM implementation, the significant change is > using dbg.value's first operand to refer to a DILocalVariable, rather > than a Value. There's some impedance mismatch here, because all the > documentation (for example in the

Yep. That diagnostic is terrible. As of r167937 we get: error: instruction requires: 32-bit mode jmp *%edx ^ -Jim On Nov 14, 2012, at 8:41 AM, Eric Christopher <echristo at gmail.com> wrote: > Most likely candidate for sure. Not a helpful error message though :( > > -eric > > > On Wed, Nov 14, 2012 at 8:17 AM, Craig Topper <craig.topper at gmail.com> wrote:

Hello, I'm trying to use clang to compile a file in an x86 machine (running i386 GNU/Linux) to ARM. In the end, all I want is for the bit code (I use -emit-llvm) getArch() result to be Triple::ARM. I tried to use "-target arm" but I get a "fatal error: 'bits/predefs.h' file not found". Is there any easy way to make the target architecture "ARM" without