similar to: git llvm push?

llvm-project/llvm> git rev-parse --git-common-dir --git-common-dir llvm-project/llvm> On Fri, May 3, 2019 at 3:48 PM Craig Topper <craig.topper at gmail.com> wrote: > I might have seen this issue. What does "git rev-parse --git-common-dir" > return for you? > > ~Craig > > > On Fri, May 3, 2019 at 12:35 PM Cameron McInally via llvm-dev < > llvm-dev

I need to use ‘createVirtualRegister’ for a specific case in my ‘eliminateFrameIndex’ function implementation. However, whenever that code is executed, I get the assertion "MachineCopyPropagation should be run after register allocation!” at a later stage. I have seen that at least a couple of backend implementations (including ARM Thumb) create virtual registers in ‘eliminatedFrameIndex’.

It is suggested in the documentation that if you would have declared a function parameter as SmallVector<Foo,N>&, it is better to instead declare it as SmallVectorImpl<Foo>&. This makes sense, but it seems to me that it is better still to declare it as ArrayRef<Foo>; a quick test suggests it compiles to the same (highly efficient) code, and adds a bit more flexibility in

13:38 < mkletzan> rjones: Not sure where to look, but when I do just `import nbd` from python on the clean installation of libnbd, I just get `ImportError: cannot import name 'Error'` I can't reproduce it: $ rpm -q python3-libnbd python3-libnbd-0.1.8-1.fc30.x86_64 $ python3 Python 3.7.3 (default, May 11 2019, 00:38:04) [GCC 9.1.1 20190503 (Red Hat 9.1.1-1)]

Hey everyone, I'd like to add some new constant foldings to ConstantExpr -- in particular ConstantExpr::get(...) and friends. But, I'm having trouble finding the correct place for adding IR tests in the /test directory. Any suggestions? Thanks, Cam -------------- next part -------------- An HTML attachment was scrubbed... URL:

Actually, sorry, my fix was for the case where you had other arguments beginning with @ that weren't response files, whereas yours has actual response files, so my patch won't help there. CCing Reid and Hans, who did a bunch of the implementation in this area. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Shoaib Meenai via llvm-dev <llvm-dev at

Am 03.05.19 um 14:01 schrieb Daniel Vetter: > [CAUTION: External Email] > > On Fri, May 3, 2019 at 12:15 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: >> Hi Christian, >> >> would you review the whole patch set? Daniel mentioned that he'd prefer >> to leave the review to memory-mgmt developers. > I think Noralf Tronnes or Gerd Hoffmann would

Am 03.05.19 um 14:01 schrieb Daniel Vetter: > [CAUTION: External Email] > > On Fri, May 3, 2019 at 12:15 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: >> Hi Christian, >> >> would you review the whole patch set? Daniel mentioned that he'd prefer >> to leave the review to memory-mgmt developers. > I think Noralf Tronnes or Gerd Hoffmann would

Jeroen Dobbelaere via llvm-dev <llvm-dev at lists.llvm.org> writes: > Hi Jesper, > >> Thanks, these are interesting differences. The CHAR_BIT and byte >> relation is established in the C standard and I would prefer the byte >> terminology. It means the same thing as addressable unit but is a bit >> shorter and probably more widely known. > > Looking

Hi Lorenzo, I’ll answer the first question you have: > I would like to use llvm-mca to estimate the IPC of a given code region. I am interested in the library version

Hi Thomas. > >> + > >> +/** > >> + * Returns the container of type &struct drm_gem_vram_object > >> + * for field bo. > >> + * @bo: the VRAM buffer object > >> + * Returns: The containing GEM VRAM object > >> + */ > >> +static inline struct drm_gem_vram_object* drm_gem_vram_of_bo( > >> + struct ttm_buffer_object

Hi Thomas. > >> + > >> +/** > >> + * Returns the container of type &struct drm_gem_vram_object > >> + * for field bo. > >> + * @bo: the VRAM buffer object > >> + * Returns: The containing GEM VRAM object > >> + */ > >> +static inline struct drm_gem_vram_object* drm_gem_vram_of_bo( > >> + struct ttm_buffer_object

On 2 Apr 2019, at 22.37, Timo Sirainen via dovecot <dovecot at dovecot.org> wrote: > > On 2 Apr 2019, at 17.03, Jan-Pieter Cornet via dovecot <dovecot at dovecot.org <mailto:dovecot at dovecot.org>> wrote: >> >> Hi, >> >> We're synching mailboxes, changing format from maildir to mdbox, using doveadm backup/doveadm sync. >> >> When

Hi All: Just wanted to wind this up and summarize the results. Although there were a few no votes, it looks like there's a consensus for adding a `isa_and_nonnull` type operator. While there were some who preferred `isa_nonnull`, it wasn't overwhelming, and since `isa_and_nonnull` is already committed, I'm going to leave it as `isa_and_nonnull` for the time being. Thanks for all

Hi Sjoerd, On Fri, May 3, 2019 at 8:19 AM Sjoerd Meijer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > I read that out-of-order cores are supported. How about in-order cores? > Would it be easy/difficult to add support for that? > > Cheers, > Sjoerd. > > I don't think that it would be difficult to support in-order superscalar cores. However, it would

Hi Chris, this was a very tempting commit to make, unfortunately it broke pattern matching of vectors of booleans. The problem is that a ConstantDataVector is only formed if the element type is one of i8, i16, etc. So vectors of funky types, or not so funky types like i1, are no longer matched. I noticed this while working on PR11948. The good thing is that the testcase there no longer crashes

Hi llvm-dev, Does LLVM's PatternMatch library support matching on GetElementPointer Instructions? I can't find anything in the API that looks promising. Thank you! Eli

On Feb 9, 2012, at 1:22 PM, Duncan Sands wrote: > Hi Chris, this was a very tempting commit to make, unfortunately it broke > pattern matching of vectors of booleans. The problem is that a > ConstantDataVector is only formed if the element type is one of i8, i16, etc. > So vectors of funky types, or not so funky types like i1, are no longer > matched. I noticed this while working

Hi Chris, >> Hi Chris, this was a very tempting commit to make, unfortunately it broke >> pattern matching of vectors of booleans. The problem is that a >> ConstantDataVector is only formed if the element type is one of i8, i16, etc. >> So vectors of funky types, or not so funky types like i1, are no longer >> matched. I noticed this while working on PR11948. The

Hi everyone, This RFC concerns the design and architecture of a generic machine instruction combiner/optimizer framework to be developed as part of the GISel pipeline. As we transition from correctness and reducing the fallback rate to SelectionDAG at -O0, we’re now starting to think about using GlobalISel with optimizations enabled. There are obviously many parts to this story as optimizations