search for: jji

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" <llvm-dev at lists.llvm.org>, llvm-dev <llvm-dev-bounces at lists.llv...

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

..., meaning contiguous instructions. It doesn’t > really support the removal of instructions between those two points, so > you’d have to synthesize a region, create a meta-iterator, or some other > intrusive modification. > > > > JB > > > > *From:* Jinsong Ji [mailto:jji at us.ibm.com] > *Sent:* Thursday, September 3, 2020 10:03 AM > *To:* Nagurne, James; jmolloy at google.com > *Cc:* llvm-dev at lists.llvm.org; Sander > *Subject:* [EXTERNAL] RE: [llvm-dev] Machinepipeliner interface. > shouldIgnoreForPipelining, actually not ignoring. > > >...

...re using the in-tree machinepipeliner, it won't have any effects, because there is NO In tree reference of this API at all. You can see the comments when James introduced this API in https://reviews.llvm.org/D67167 Best, Jinsong Ji (纪金松), PhD. XL/LLVM on Power Compiler Development E-mail: jji at us.ibm.com [Inactive hide details for Sander via llvm-dev ---06/02/2020 03:47:53 PM---Hi all, I think there is a mistake in the machinepipe]Sander via llvm-dev ---06/02/2020 03:47:53 PM---Hi all, I think there is a mistake in the machinepipeliner interface. In the From: Sander via llvm-dev &lt...

...e on creating a good abstraction and improving the code. I appreciate that you’ve started to think/work on this problem, so I’d like to help out to pursue this direction. Thanks, Brendon From: James Molloy <james at jamesmolloy.co.uk> Sent: Monday, July 15, 2019 11:05 AM To: Jinsong Ji <jji at us.ibm.com> Cc: Brendon Cahoon <bcahoon at quicinc.com>; Hal Finkel <hfinkel at anl.gov>; LLVM Dev <llvm-dev at lists.llvm.org> Subject: [EXT] Re: MachinePipeliner refactoring Hi Jingsong, Thanks for testing out the prototype! I'm not surprised there are errors in that...

...oring 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 jamesmolloy.co.uk> To: LLVM Dev <llvm-dev at lists.llvm.org>, jji at us.ibm.com, bcahoon at quicinc.com, Hal Finkel <hfinkel at anl.gov> Date: 07/15/2019 06:16 AM Subject: [EXTERNAL] MachinePipeliner refactoring Hi Brend...

..., meaning contiguous instructions. It doesn’t > really support the removal of instructions between those two points, so > you’d have to synthesize a region, create a meta-iterator, or some other > intrusive modification. > > > > JB > > > > *From:* Jinsong Ji [mailto:jji at us.ibm.com] > *Sent:* Thursday, September 3, 2020 10:03 AM > *To:* Nagurne, James; jmolloy at google.com > *Cc:* llvm-dev at lists.llvm.org; Sander > *Subject:* [EXTERNAL] RE: [llvm-dev] Machinepipeliner interface. > shouldIgnoreForPipelining, actually not ignoring. > > >...

..., meaning contiguous instructions. It doesn’t > really support the removal of instructions between those two points, so > you’d have to synthesize a region, create a meta-iterator, or some other > intrusive modification. > > > > JB > > > > *From:* Jinsong Ji [mailto:jji at us.ibm.com] > *Sent:* Thursday, September 3, 2020 10:03 AM > *To:* Nagurne, James; jmolloy at google.com > *Cc:* llvm-dev at lists.llvm.org; Sander > *Subject:* [EXTERNAL] RE: [llvm-dev] Machinepipeliner interface. > shouldIgnoreForPipelining, actually not ignoring. > > >...

...U 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 llvm-dev" <llvm-dev at lists.llvm.org> To: Simon Pilgrim <llvm-dev at redking.me.uk>, "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, "powerllvm at ca.ibm.com" <powerllvm...

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

Hello, Is there a way for Phabricator to retain the patches as originally uploaded? When using the "Download Raw Diff" button, it seems Phabricator reformats the patch, loosing the parent commit along the way, so often patches don't apply. The following works, because I've got the latest checkout on master, and the patch was rebased recently: F:\llvm-project>curl

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

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

...we should consider before changing the default behavior. FYI. This is a patch https://reviews.llvm.org/D73566 that show the change and affected in tree testcases. Reviews and comments are highly appreciated, thank you! Best, Jinsong Ji (纪金松), PhD. XL/LLVM on Power Compiler Development E-mail: jji at us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200128/31a7c115/attachment.html>

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

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

...uaUEbtUu STic5P////8v3xYcfmxUvTi1RrjGN7os8owAZWmqixpk2gd4vSDHhfi3+v+t1E/XrfTF6MUlOMP5 4MQJF+p+WksL/P83aQYpJWUAs1rghTlhQc8qJrwFSP/////S9KhhdIZlL4og3aZpHzrwq6j/wRhJ D6oi6JMZ5pH14f//3+AVH2ETXIAnjBLp6mF7VgXiltw/yYrZMEu/8ML/Z0TSJaB28zqFImRqKR32 1rfB/TX/f+v/UxUOQJcBLrXGjsrrcXyBtaf+N41TrFBitt3/////juFDIl7sJJixCfQPxjjpUAwM 5Fnbze80RaEeK6mitSH//1/ghP8UDdBqqNhmBfE+7zxZs3subWQm8Cqv/y/8/4/BZ8H15UFLc3pA RVmf5Ih2ZImVuE12M2dY//+3+H2h94Kd9OnVcqQCX7t9+4RFygmWAPls1v////8SyL2kjM/AYBiZ WBq8OcAB2/R7/ghE4xTGrqHfKb8y5f////+QtGF9BDjzxh+KnRYWvU+Bhkea93tlYThcaPXMkZRN vf//v9RoMpgo2ajkHbcN3ftEAoEGpzRiDLR11yn6//+lagAE9vefZsV...

Hello list. I'm trying to rebuild the 2.6.9.67.0.20.EL kernel, but it fails even without modifications. How did I try it? Created a (non-root) build environment (not a mock ) Installed the kernel.scr.rpm and did a rpmbuild -ba --target=`uname -m` kernel-2.6.spec 2> prep-err.log | tee prep-out.log The build failed at the end: Processing files: kernel-xenU-devel-2.6.9-67.0.20.EL Checking