similar to: Applying patches from Phabricator?

Hello, I sometime forget to set the "Repository" when uploading a patch on Phabricator, and that prevents from adding llvm-commits as a subscriber. [cid:image001.png at 01D61A45.E388B060] Would it make sense to set 'LLVM Github Monorepo' as a default? Or subscribe 'llvm-commits' automatically when creating a patch? Thanks! Alex. -------------- next part --------------

Hi Nicholas, The admin of the buildbot is aware of this, will handle it after long weekend. Thanks. Best, Jinsong Ji (纪金松), PhD. XL/LLVM on Power Compiler Development E-mail: jji at us.ibm.com From: Nicholas Krause <xerofoify at gmail.com> To: Jinsong Ji <jji at us.ibm.com>, "Finkel, Hal J." <hfinkel at anl.gov> Cc: "llvm-dev at lists.llvm.org"

Hello, as discussed here in more detail: https://reviews.llvm.org/D81583 the introduction of the C++20 [[no_unique_address]] attribute exposes an ABI issue on platforms that require special handling for structs/classes that are "equivalent" to a single floating-point member (or in some cases, a "homogeneous" set of floating-point members). This is because we can now for the

Sorry to bring this thread from 3 months ago back, but I’m running into this issue too. I do see that shouldIgnore is not called in the MachinePipeliner, however, James’ comment doesn’t really resolve the issue or make the story any clearer. My summary of the comment is: “Hexagon and PPC9 do not need to ignore any instructions. However, in the case that you do, such as when the indvar update is

-- The C compiler identification is GNU 7.3.1 -- The CXX compiler identification is GNU 7.3.1 According to buildbot log here http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/37730/steps/cmake%20stage%201/logs/stdio for Simon's example ICE. Best, Jinsong Ji (纪金松), PhD. XL/LLVM on Power Compiler Development E-mail: jji at us.ibm.com From: "Finkel, Hal J. via

Hi James, Having not worked on this for circa one year I've gone and refreshed my memory. We have a pretty capable implementation of swing modulo scheduling downstream, distinct from the MachinePipeliner implementation. Historically, MachinePipeliner had very tight coupling between the finding of a suitable schedule and emitting the code that adheres to that schedule. I spent quite a bit of

Hi James, One last thing - is your target upstream? or are you working on a downstream target? Cheers, James On Tue, 8 Sep 2020 at 23:02, Nagurne, James <j-nagurne at ti.com> wrote: > I greatly appreciate you going back to gather that intel, James. It > actually helps my understanding of the whole pipeliner puzzle quite a bit! > > > > I did identify, like you, that the

On Thu, Oct 24, 2019 at 2:22 PM Jinsong Ji <jji at us.ibm.com> wrote: > Looks like to me that your clang is too old. > > clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) > > clang 3.8.0 was released on 08 Mar 2016. > > While vec_xl was added in https://reviews.llvm.org/rL286455 onNov 11 > 2016, which is around half an year later then 3.8.0. > > Can you

Hi James, Adding Hendrik, who has taken over ownership of the downstream code involved. I can also add background about the rationale, of that helps? It was added to ignore induction variable update code (scalar code) that is rewritten when we unroll / peel the prolog epilog anyway. Targets like Hexagon or PPC with dedicated loop control instructions for pipelined loops don't need this, but

Hi all, I think there is a mistake in the machinepipeliner interface. In the TargetInstrInfo.h in the class PipelinerLoopInfo there is a function "bool shouldIgnoreForPipelining(const MachineInstr *MI)". The description says that if this function returns true for a given MachineInstr it will not be pipelined. However in reality it is not ignored and is being considered for

Hi Brendan (and friends of MachinePipeliner, +llvm-dev for openness), Over the past week or so I've been attempting to extend the MachinePipeliner to support different idioms of code generation. To make this a bit more concrete, there are two areas where the currently generated code could be improved depending on architecture: 1) The epilog blocks peel off the final iterations in reverse

Hi James: Personally, I like the idea of refactoring and more abstraction, But unfortunately, I don't know enough about the edges cases either. BTW: the prototype is still causing quite some Asseertions in PowerPC - some nodes are not generated in correct order. Best, Jinsong Ji (纪金松), PhD. XL/LLVM on Power Compiler Development E-mail: jji at us.ibm.com From: James Molloy <james at

Hi Everyone, I'm having trouble figuring out a compile failure on ppc64le. The failure is at https://travis-ci.org/noloader/cryptopp-autotools/jobs/602187190 . The message is: /bin/bash ./libtool --tag=CXX --mode=compile clang++ -DHAVE_CONFIG_H -I. -DCRYPTOPP_DISABLE_POWER8 -pipe -mcpu=power7 -mvsx -maltivec -g -O2 -MT libppc_power7_la-ppc_power7.lo -MD -MP -MF

Hi James, I also think that refactoring the code generation part is a great idea. That code is very complicated and difficult to maintain. I’ve wanted to rewrite that code for a long time, but just have never got to it. There are quite a few edge cases to handle (at least in the current code). I’ll take a deeper look at your patch. The abstractions that you mention, Stage and Block, are good

Hi, everyone, I would like to know if anyone is still making use of the support in the PowerPC backend for the IBM BG/Q supercomputer, including the support for its QPX vector instruction set. If you are, please reply. I'm not aware of any still-running BG/Q machines, and if no one is making use of this functionality, I propose that we remove it. Thanks again, Hal Hal Finkel Lead, Compiler

http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/37730/ is an example of the ICE when D64146/rL370584 landed. On 01/09/2019 02:23, Florian Hahn via llvm-dev wrote: > Hi, > >> On Aug 31, 2019, at 15:14, Nandor Licker via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hello PowerPC fans, >> >> I am attempting to land D64146 and the PowerPC

cc Paul / MyDeveloperDay De : llvm-dev <llvm-dev-bounces at lists.llvm.org> De la part de David Blaikie via llvm-dev Envoyé : April 8, 2020 10:21 PM À : Raphael “Teemperor” Isemann <teemperor at gmail.com>; Manuel Klimek <klimek at google.com> Cc : llvm-dev <llvm-dev at lists.llvm.org> Objet : Re: [llvm-dev] Outdated Phabricator version on reviews.llvm.org breaks Google

Can you please try using Ninja instead? cmake -G Ninja f:/svn/llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_OPTIMIZED_TABLEGEN=true -DLLVM_EXTERNAL_LLD_SOURCE_DIR=f:/svn/lld -DLLVM_TOOL_LLD_BUILD=true -DLLVM_ENABLE_LLD=true -DCMAKE_C_COMPILER="C:/Program Files/LLVM/bin/clang-cl.exe" -DCMAKE_CXX_COMPILER="C:/Program Files/LLVM/bin/clang-cl.exe" -DCMAKE_LINKER="C:/Program

Times for lld compiled with LTO: Input File Reading: 1430 ms ( 3.3%) Code Layout: 486 ms ( 1.1%) PDB Emission (Cumulative): 41042 ms ( 94.6%) Add Objects: 33117 ms ( 76.4%) Type Merging: 25861 ms ( 59.6%) Symbol Merging: 7011 ms ( 16.2%) TPI Stream Layout: 996 ms ( 2.3%) Globals Stream Layout:

I think its a huge bug that it doesn't raise any errors or warnings about it. But I will open a ticket on cmake, they should be using clang-cl.exe and lld-link.exe if T="llvm" probably set host to 64 bit as well. On Mon, Feb 25, 2019 at 3:34 PM Zachary Turner <zturner at google.com> wrote: > > I don’t think changing the compiler or linker is supported with the vs