similar to: [LLVMdev] Metadata on Machine Instructions?

I'm investigating a bug associated with debug information that manifests itself in the XCore backend (PR11105). I'd like to understand what the expected behavior of eliminateFrameIndex() is when it is called on a dbg_value machine instruction. Currently the XCore target replaces the frame index with the frame register and sets the next operand to the byte offset from the frame

On 2 Mar 2018, at 11:09, Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I am working on a target which requires to generated two > instructions for a single branch instruction. > ex: > imm 1 > br r4,0xabcd > branch address is 0x1abcd, imm has the upper 16 bits and br has > lower 16 bits. > > Can anyone let me know how to write

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 Fri, Mar 2, 2018 at 4:59 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 2 Mar 2018, at 11:09, Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> I am working on a target which requires to generated two >> instructions for a single branch instruction. >> ex: >> imm 1 >> br r4,0xabcd >> branch

> 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: >> >>

On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: > I'm investigating a bug associated with debug information that manifests > itself in the XCore backend (PR11105). I'd like to understand what the > expected behavior of eliminateFrameIndex() is when it is called on a > dbg_value machine instruction. That is up to the target. The TII::emitFrameIndexDebugValue() hook is

----- Original Message ----- > From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Geoff Berry" <gberry at codeaurora.org> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, August 25, 2016 3:05:48 PM > Subject: Re: [llvm-dev] invariant.load metadata semantics > ----- Original Message ----- > >

On 10/10/11 19:19, Jakob Stoklund Olesen wrote: > On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: >> I'm investigating a bug associated with debug information that manifests >> itself in the XCore backend (PR11105). I'd like to understand what the >> expected behavior of eliminateFrameIndex() is when it is called on a >> dbg_value machine instruction. >

As of Monday, I finally got a preliminary patch passing check and check-clang with the metadata-value split. It's rather massive, but mostly NFC. I've managed to keep the bitcode format, assembly syntax, and C API unchanged, except for a few semantic restrictions that I'll separate out and commit ahead of time via assertions to the extent I can. (Obviously I plan to clean up

On Sep 10, 2009, at 10:48 AM, Devang Patel wrote: > The proposed solution is to optionally attach debug information with > llvm instruction directly. A new keyword 'dbg' is used to identify > debugging information associated with an instruction. The debugging > information, if available, is printed after the last instruction > operand. The debugging information entry uses

----- Original Message ----- > > > > On Sep 7, 2013, at 7:41 AM, Hal Finkel < hfinkel at anl.gov > wrote: > > > > > On Feb 7, 2013, at 10:58 PM, Hal Finkel < hfinkel at anl.gov > wrote: > > > > > As long as this is brainstorming time, I actually like the idea of > an > llvm.invariant intrinsic that the optimizers know to

On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 10 Sep 2013, at 10:13, Kostya Serebryany <kcc at google.com> wrote: > > > How did you come with 320 bits? > > 320=64*4+64, which is the size of the metadata table entry plus pointer > size, > > > Sorry, that should have been 192. The specification allows the

On Tue, Feb 12, 2013 at 4:33 AM, Shemer, Anat <anat.shemer at intel.com> wrote: > Hi, > > Is it possible to give an instruction metadata that accepts function > argument as operand? The 2 functions are in the same module so the metadata > operand can be resolved. Here is how I imagine it should look like: > > define i32 @f(i32 %v) { > %v0 = call i32 @f1 (i32 %v,

On Thu, 2012-01-26 at 14:10 -0800, Dan Gohman wrote: > On Jan 26, 2012, at 12:54 PM, Devang Patel wrote: > > > > On Jan 26, 2012, at 11:15 AM, Dan Gohman wrote: > > > >> or what optimizers must do to preserve it. > > > > The number one reason behind metadata is to have a mechanism to track values while being completely transparent to optimizer. If you

Hey Guys ! I'm interested to participate in Google Summer of Code 2018 for LLVM. Any Projects (new features or reimplementation) related to recent " Meltdown & Spectre " Problem. I'm a beginner in Compiler Technology. Could you please recommend some videos or blog post about "*Introduction to LLVM internals ". *Because I find it difficult to understand LLVM IR

On Sep 10, 2009, at 10:48 AM, Devang Patel wrote: > Hi All, > > Today, debugging information is encoded in LLVM IR using various > llvm.dbg intrinsics, such as llvm.dbg.stoppoint. For exmaple, Right. > This approach has several disadvantages. > - The llvm.dbg.stoppoint()s act like hurdles to the optimizer. The > LLVM customers expect that the optimizer does not trip over

Hi Christopher, unfortunately, there still no facility/api able to support propagation of IR Metadata down to the backend. Nonetheless, I and another guy are working on a draft of proposal addressing specifically this need. Here you find the link to the last message of the on-going thread: http [://] lists [.] llvm [.] org/pipermail/llvm-dev/2020-November/146387.html Feel free to join the

Hi, everyone, We had a great call last month, and progress is definitely being made on several fronts. The notes from our last call are available here: https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit#heading=h.vpxs8lkuxy79 and, also, pasted below. DOODLE POLL: As we discussed on our last call, I would like to schedule a regular call to discuss

On 10 Sep 2013, at 10:28, Kostya Serebryany <kcc at google.com> wrote: > > > > On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 10 Sep 2013, at 10:13, Kostya Serebryany <kcc at google.com> wrote: > > > How did you come with 320 bits? > > 320=64*4+64, which is the size of the metadata table entry plus

On Sep 7, 2013, at 7:41 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> On Feb 7, 2013, at 10:58 PM, Hal Finkel < hfinkel at anl.gov > wrote: >> >> >> >> >> As long as this is brainstorming time, I actually like the idea of >> an >> llvm.invariant intrinsic that the optimizers know to ignore. I >> like >> it for other