search for: istm

...g once in X86RegisterInfo.cpp and once in X86FrameLowering.cpp, The method TargetRegisterInfo::eliminateCallFramePseudoInstr doesn't appear to really belong in this interface. It adds instructions into the MachineFunction given to it, which isn't what TargetRegisterInfo is supposed to do. ISTM that eliminateCallFramePseudoInstr belongs in TargerFrameLowering, since it's being used during prolog/epilog insertion. Moving it there would avoid the code duplication and possibly other layering problems. What do you think Eli P.S. I'm asking in llvmdev before proposing an actual patc...

...[LLVMdev] Bug in InsertElement constant propagation? On 1/14/15 11:12 AM, Raoux, Thomas F wrote: > Ha here is what I was missing. Thanks Jon. It still seems to me that the transformation of LLVM IR is invalid is that right? I don't know if IR is required to preserve NaN bit patterns, but ISTM that it would be better if it did. > I assume we shouldn't be converting APFloat to float in order to avoid such problems? Yes, I think that's the correct fix. Jon -- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded

...uses (https://github.com/apple/swift/blob/master/lib/LLVMPasses/LLVMMergeFunctions.cpp <https://github.com/apple/swift/blob/master/lib/LLVMPasses/LLVMMergeFunctions.cpp>). Is anyone actively working on enabling MergeFunctions in LLVM's default pipelines? Is there a roadmap for doing so? ISTM that preventing miscompiles when merging functions is a serious, unsolved problem. I.e., it's hard for the MergeFunctions pass to be *really sure* that two functions are a) really identical and b) safe to merge. Is there a systematic solution at the IR-level, given that the semantics of IR are...

...# %entry movq %rdi, -8(%rsp) leaq 8(%rdi), %rax ret .Ltmp0: .size bar, .Ltmp0-bar .section ".note.GNU-stack","", at progbits The first instruction in "bar" is not clear. Why is it needed? It seems harmless, but does it serve any purpose? Alignment? ISTM that the leaq suffices to pefrorm the actual task of the function. Is this a missed optimization of some sort? Thanks in advance, Eli

> ISTM that eliminateCallFramePseudoInstr belongs in > TargerFrameLowering, since it's being used during prolog/epilog > insertion. Moving it there would avoid the code duplication and > possibly other layering problems. > What do you think Go ahead and move. It's s historical artifact...

...t looks like that's the correct way to handle this. This leads me to my next question: as I make more and more functions with the EE, it slows down. I am re-using the Module, ExistingModuleProvider, and ExecutionEngine, and pumping the parser like so: M = ParseAssemblyString(AsmString, M); ISTM that there should be a way of creating multiple modules/EEs but I ran into trouble when I tried that (some time ago). Is there a way around this ? I'm looking for scalability. Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheo...

..., 5 May 2006, Simon Burton wrote: > This leads me to my next question: as I make more and more functions > with the EE, it slows down. I am re-using the Module, ExistingModuleProvider, > and ExecutionEngine, and pumping the parser like so: > M = ParseAssemblyString(AsmString, M); > ISTM that there should be a way of creating multiple modules/EEs but I ran > into trouble when I tried that (some time ago). Can you quantify what you mean? How does it "slow down"? -Chris -- http://nondot.org/sabre/ http://llvm.org/

On 18 December 2014 at 21:32, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > I think this will help one facet of your problem: > http://reviews.llvm.org/D6584 I don't think so, because the tests don't time out, it's a buffering issue... --renato

On Mon, Nov 2, 2015 at 7:19 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Why does this need to be an intrinsic (as opposed to generic "unknown > function" to llvm)? > > Secondly, have you looked into a volatile store / load to an alloca? That > should work with PNaCl and WebAssembly. > > E.g. > > define i32 @blackbox(i32 %arg) { >

...n be expected. There used to be hacks that worked with the newer versions of iTunes to open-up its present closed sharing. Another problem with current iTunes is that IIRC only 5 local machines can share your playlist at the same time, so your project would still be limited too much that way ISTM. It isn't DAAP doing the limiting btw, so a proper implementation of it should allow for any number of listeners.) I'm wondering if there are plans to include DAAP into Icecast or any other *cast projects? It'll only become a standard if we-all make it so. ;) Concerned abo...

...looks more like the virtio_block device simply has the wrong >> DMA mask to begin with. For virtio-pci we set the streaming DMA mask to >> 64 bits - should a platform device not be similarly capable? > > If it's not, then turning off DMA API will cause random corruption. > ISTM one way or another the bug is in either the DMA ops or in the > driver initialization. OK, having looked a little deeper, I reckon virtio_mmio_probe() is indeed missing a dma_set_mask() call compared to its PCI friends. The only question then is where does virtio-mmio stand with respect to lega...

...looks more like the virtio_block device simply has the wrong >> DMA mask to begin with. For virtio-pci we set the streaming DMA mask to >> 64 bits - should a platform device not be similarly capable? > > If it's not, then turning off DMA API will cause random corruption. > ISTM one way or another the bug is in either the DMA ops or in the > driver initialization. OK, having looked a little deeper, I reckon virtio_mmio_probe() is indeed missing a dma_set_mask() call compared to its PCI friends. The only question then is where does virtio-mmio stand with respect to lega...

Ha here is what I was missing. Thanks Jon. It still seems to me that the transformation of LLVM IR is invalid is that right? I assume we shouldn't be converting APFloat to float in order to avoid such problems? -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] Sent: Wednesday, January 14, 2015 9:39 AM To: Raoux, Thomas F; LLVM Developers Mailing List

...hn.redhat.com/errata/RHBA-2008-0083.html Then there's a recent discussion on the topic of who is responsible for calling sfence on the gcc mailing list: http://www.mail-archive.com/gcc at gcc.gnu.org/msg45939.html Unfortunately, that thread didn't seem to have any firm conclusion, but ISTM that the current default assumption is (b): anything that uses movnti is assumed to surround such uses with memory fences so that other code doesn't need to. James

On May 29, 2015, at 10:08 PM, Rui Ueyama <ruiu at google.com> wrote: > Large part of the difficulties in development of the current LLD comes from over-generalizataion to share code between pretty much different file formats. ISTM the problem that's been described isn't that code is shared between file formats, but that an internal representation was chosen based on what MachO required, which in the end turned out to be unsuitable for representing the greater generality allowed by the other two file formats. You sta...

...l benchmarks meaningful (and I can't), I'm saying that it would be useful in Rust in ensuring that tests/benches aren't invalidated simply because a computation wasn't performed. Past that, if you want to ensure a particular optimization does a > particular thing on a benchmark, ISTM it would be better to generate the > IR, run opt (or build your own pass-by-pass harness), and then run "the > passes you want on it" instead of "trying to stop certain passes from doing > things to it". > True, but why would you want to force that speed bump onto o...

...> leaq 8(%rdi), %rax > ret > .Ltmp0: > .size bar, .Ltmp0-bar > > > .section ".note.GNU-stack","", at progbits > > The first instruction in "bar" is not clear. Why is it needed? It > seems harmless, but does it serve any purpose? Alignment? ISTM that > the leaq suffices to pefrorm the actual task of the function. Is this > a missed optimization of some sort? > I should add that if I manually hack takeaddr.ll to avoid the alloca and store, instead using %table directly in the GEP, the movq goes away and only leaq remains. Eli

Hi Simon, You're probably right. LLVM's instruction selector is recursive so it can run out of stack space. Select_store used to have enormous stack frame (thanks to some gcc issues), we had to do all kinds of tricks to get it under control. I just took a look at it, it's around 0.7k. It used to be around 20k on x86 Mac OS X. It's also possible that it has gotten into a

...ement constant propagation? > > > > On 1/14/15 11:12 AM, Raoux, Thomas F wrote: >> Ha here is what I was missing. Thanks Jon. It still seems to me that the transformation of LLVM IR is invalid is that right? > I don't know if IR is required to preserve NaN bit patterns, but ISTM that it would be better if it did. >> I assume we shouldn't be converting APFloat to float in order to avoid such problems? > Yes, I think that's the correct fix. > > Jon > > -- > Jon Roelofs > jonathan at codesourcery.com > CodeSourcery / Mentor Embedded >...

...utput of command --help | grep relax): -mc-relax-all - When used with filetype=obj, relax all fixups in the emitted object file It also appears in clang: -mrelax-all (integrated-as) Relax all machine instructions I'd like to discuss the naming and semantics of this flag, because ISTM at least the name is misleading. If I understand correctly, relaxation is always required in MC (*) to produce correct code, and in fact MC always performs relaxation, whether mc-relax-all was passed or not. What mc-relax-all seems to affect is how certain decisions in MC are handled. Specifically...