similar to: [RFC] Print FP constant assembly in hexadecimal form instead of decimal

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"

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

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

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

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

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

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

Hi there, could somebody help me to convert a decimal number into a hexadecimal number? I know that there is the function "sprintf", but the numbers I want to convert consist of 20 or more numbers. "Spintf" is not able to convert these big numbers. Thanks for any help. Antje [[alternative HTML version deleted]]

Hi, do you know, a method to convert an decimal value (integer) to the corresponding hexadecimal value ? thinks for help. Romain -- Lorrilli?re Romain UMR 8079 Laboratoire Ecologie, Syst?matique et Evolution B?t. 362 Universit? Paris-Sud 91405 Orsay cedex France tel : 01 69 15 56 85 fax : 01 69 15 56 96 mobile : 06 81 70 90 70 email : romain.lorrilliere at ese.u-psud.fr

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

These are some points stimulated by reading about C history (and related in their implementation). 1) On some platforms > as.integer("0xA") [1] 10 but not all (not on Solaris nor Windows). We do not define what is allowed, and rely on the OS's implementation of strtod (yes, not strtol). It seems that glibc does allow hex: C99 mandates it but C89 seems not to allow it. I

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