similar to: RFC: Add a way to interleave source code in assembler output

On 03/16/2017 06:22 PM, Mehdi Amini via llvm-dev wrote: >> On Mar 16, 2017, at 10:29 AM, Roger Ferrer Ibanez via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> I'm implementing interleaved source in assembly output. Early reviews raised the concern > Is there a patch up for review? https://reviews.llvm.org/D30898

Hi all, I'm implementing interleaved source in assembly output. Early reviews raised the concern that the current implementation will be opening files (using a llvm::MemoryBuffer) that are likely to be in the memory of the front end (commonly clang but I think we want this to be front end agnostic). I'm now exploring ideas to avoid reopening files and let LLVM reuse the files the FE had

When I am constructing sequences of instructions during custom lowering, I would like to be able to also add a comment that appears in the generated assembly with '-S -fverbose-asm'. There is a large set of 'add*' functions to attach additional information to the MI, but I don't see one for adding comments. Is there a method I can call to attach an arbitrary string

Michael Smith wrote: >Whilst I accept that there are many good uses for chunked data, I >think the transformation is trivial, particularly given certain >characteristics of the Ogg container. Remember, the data, if you read >an ogg stream into memory, is _already_ likely to be non-contiguous, >due to ogg's structure. It's trivial, and has insignificant additional

Hi Alexandra, > I upgraded to llvm 2.8 and when I generate *.ll files from C/C++ with > clang -S -emit-llvm I obtain a *.ll file in which instructions and > basicblocks have no names. > I tried as well compiling with the -g option, but no names were given. with dragonegg using -fverbose-asm causes names to be generated in the IR. Maybe clang could do this to? Ciao, Duncan.

Regarding InterleavedAccessPass - sure, but proper strided/interleaved access optimization ought to have a positive impact even without target support. Case in point - Hal enabled it on PPC last September. An important difference vs. x86 seems to be that arbitrary shuffles are cheap on PPC, but, as I said below, I hope we can enable it on x86 with a conservative cost function, and still get

There is no generic mechanism as far as I know. You can look at AsmPrinter.cpp/emitComments() to see what situations trigger comments at the moment. - Matthias > On Feb 3, 2018, at 4:40 AM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > When I am constructing sequences of instructions during custom lowering, I would like to be able to also add a

I work on the LLILC team, and we are trying to send debug line info through to the CoreCLR EE without using an EventListener because we need to send extra info (more than just available in DebugLoc) like if it’s a call instruction, a call site, etc. We thought extending AsmPrinterHandler would be useful since it seems to have information about debug locations, label offsets, and instruction

Hi all, The remaining issue to be decided for the OggPCM2 spec is the support of chunked vs interleaved data. Just so that everyone understands what we are talking about, consider a stereo file that gets stored as an OggPCM file. Within an OggPCM packet, the audio samples for the left and right channels can be stored as interleaved where the samples would be: l0, r0, l1, r1, ..... lN, rN

On Jul 13, 2009, at 11:29 AM, David Greene wrote: > On Monday 13 July 2009 13:13, Chris Lattner wrote: > >>> We're not going to submit our line number stuff anyway (it's too >>> much of a >>> hack) but we would like the comment infrastructure to be there. >> >> DebugLoc is there. The transition isn't complete at the LLVM IR >> level,

Hi Michael, Sometime back I did some experiments with interleave vectorizer and did not found any degrade, probably my tests/benchmarks are not extensive enough to cover much. Elina is the right person to comment on it as she already experienced cases where it hinders performance. For interleave vectorizer on X86 we do not have any specific costing, it goes to BasicTTI where the costing is not

On 11/15/05, Erik de Castro Lopo <mle+xiph@mega-nerd.com> wrote: > Hi all, > > The remaining issue to be decided for the OggPCM2 spec is the support > of chunked vs interleaved data. I think interleaved is the obvious choice - that's what most audio applications are used to dealing with, it's what we need to feed to audio hardware in the end usually, etc. Whilst I

Anyone know if it''s possible to interleave two IP packets when using PPPoA and VC based lines? Can it be done with any PPPoE implementations? The goal is to reduce the delay when you have a high priority packet waiting, but a lower priority (large) packet already started going out ahead of this packet. I don''t want the overhead of much smaller MTU, which is the other way

(background) The CoreCLR expects a JIT to produce a MSIL bytecode offset to code offset mapping annotated with a few extra bits denoting if it’s prolog/epilog, or it’s a call, or if there’s operands remaining on the MSIL virtual stack in some cases. Our initial prototype has the MSIL offset stashed in the line number field. We could stash the extra bits in the column info but that’s starting to

NOTE: I have read the FAQ, Verzani's book, Rtips, and googled. For various reasons I don't want to use a density plot when comparing two distributions, I would prefer to have interleaved histograms over the same ranges. In addition to this, I would also like to normalize the two histograms so that both of their max Y values are the same (so I can compare relative distributions within

Hey everyone, I'm looking into extending AsmPrinterHandler out of tree, to communicate information back to the CoreCLR EE, but all of the headers are in the lib directory. Is there any way to extend it out of tree, or is that not supported? The reason I'd like to do this out of tree is because we want to include clr headers as well, and we don't want to introduce that into llvm

On Fri, Oct 31, 2008 at 10:38:50AM -0700, Mike Stump wrote: > On Oct 31, 2008, at 9:40 AM, Jack Howarth wrote: >> However in current llvm svn, when I compile code with llvm-gfortran, I >> get these warning >> flags passed by default so that I get bogus warnings of... >> >> f951: warning: command line option "-Wformat" is valid for C/C++/ >>

Interleaved access is not enabled on X86 yet. We looked at this feature and got into conclusion that interleaving (as loads + shuffles) is not always profitable on X86. We should provide the right cost which depends on number of shuffles. Number of shuffles depends on permutations (shuffle mask). And even if we estimate the number of shuffles, the shuffles are not generated in-place. Vectorizer

On Monday 13 July 2009 15:46, Chris Lattner wrote: > Well sure, but how is that relevant? Just generate llvm.stoppoint and > isel turns them into debug locs. Just because debugloc isn't on > llvm::Instruction doesn't mean you don't get line numbers :). You're right, it's not a big hurdle. > > Ok, here's an example: > > > > movl

We'll be doing something similar for our OpenVMS port.  Right now I'm using "AsmStreamer->GetCommentOS()" and writing to the stream at the assembler level but that gets aligned on a right-side column (the column is hardcoded) and you have to be in verbose mode.  So if you come up with something or have a quick design, post it so perhaps we can leverage each other's work.