similar to: [GlobalISel] Extended inline assembler support

Hi, I would like to start a new porting of GlobalIsel for RISCV. An initial patch about GlobalIsel infrastructure for RISCV was ready now: https://reviews.llvm.org/D65219 There is another porting patch https://reviews.llvm.org/D41653 posted by Leslie Zhai at the end of 2017. I have checked with Leslie about the status of this patch.He has stopped developing it since some questions need be

This question came about through reviewing work from Leslie Zhai on GlobalISel support for RISC-V, which also motivated me to revisit code which I've always felt was a bit clunky. Calling convention lowering in LLVM is typically handled by functions conforming to the CCAssignFn typedef: typedef bool CCAssignFn(unsigned ValNo, MVT ValVT, MVT LocVT,

Hi LLVM developers, Don't be quiet :) we need your suggestions for supporting custom CCState, CCAssignFn in D41700. And also RegisterBank in D41653. because it needs to consider about how to support variable-sized register classes concept implemented in D24631. And I think you might have same question when porting to GlobalISel for your Targets, so please give us some directions, thanks

On 4 January 2018 at 17:10, Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. Thanks for the insight Daniel, much appreciated. >> * MipsCCState: adds bool

> On 4 Jan 2018, at 10:51, Alex Bradbury <asb at lowrisc.org> wrote: > > On 4 January 2018 at 17:10, Daniel Sanders via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>> On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> I haven't dug into the GlobalISel calling convention code much but I can comment on the

I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. > On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > This question came about through reviewing work from Leslie Zhai on GlobalISel > support for RISC-V, which also motivated me to revisit code which I've always > felt was a

Hi Leslie, On 20 December 2017 at 10:51, Leslie Zhai via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Sorry, I am apprentice of lowRISC, and meet new bug when porting GlobalISel > to RISCV target > https://github.com/xiangzhai/llvm/commit/b3f91ea54d9fee0ef7e73a32c6b8456bbe252811 > > > In file included from >

Just realized that BasicTransformInfoClass is an immutable pass. Not sure how to reconcile this with fact that there will be different answers needed depending on the subtarget. Seems like BasicTansformInfoClass should become a function pass that does not modify anything. On 03/22/2013 09:43 AM, Reed Kotler wrote: > Another way to do this would to be to have a reset virtual function >

Hi Reed, We will need to reconstruct the target machine and the TTI chain when the function attributes change. We currently don't have code for doing that but I suggest that you talk with Bill Wendling about the best way to implement this. Thanks, Nadav On Mar 22, 2013, at 11:30 AM, Reed Kotler <rkotler at mips.com> wrote: > Just realized that BasicTransformInfoClass is an

For being able to change subtargets within a compilation unit, among other things, I need to be able to change the target lowering class that is used by BasicTTI For example we have a mips16 and non mips16 version. On the original call that creates this class, I'd like to pass the address of the address of the TargetLoweringBase class. That way I can insert a function pass before this

Another way to do this would to be to have a reset virtual function which is passed the Function, and the address of TLI so that it could be modified. This seems somewhat cleaner. The reset virtual function would be added to base class TargetLoweringBase. On 03/22/2013 09:22 AM, reed kotler wrote: > For being able to change subtargets within a compilation unit, among > other things, I

Hello, To any out-of-tree targets, please be aware that I intend to commit a patch that will break the build of any target implementing TargetLoweringBase::isFMAFasterThanMulAndAdd, for the reasons described below. (Basically, the current interface definition is broken and not followed, and no in-tree target was doing the right thing with it, so it is unlikely any out-of-tree target is either...)

Hi Michael, > On Jan 13, 2017, at 6:38 PM, Michael Kuperstein <mkuper at google.com> wrote: > > As a person not developing on GlobalISel, I can already play with it by setting the flag. ;-) > > The main (and huge) benefit I see is that it will get tested by default. I agree. > So, I think it's mainly a question of maturity - if my (non-GlobalISel) change breaks

Hi, I would like to get rid of the logic around disabling GlobalISel from the build. *** Context *** So far, GlobalISel has been this framework built up on the side for about two years. Now, we are close to a point where having it being optional impedes our ability to implement the right things. For instance, checks that would fit naturally in the MachineVerifier are directly done during the

Hi LLVM developers, I am not available from February 11th to February 25th due to Chinese Spring Festival and my sincere thanks goto: Anna Zaks:     She lead me to the LLVM family and reviewed my patch for clang analyzer MallocChecker carefully and patiently. Дуже дякую Artem Dergachev:     He reviewed my patches for clang analyzer some Checkers carefully. Большое спасибо Dylan McKay:

We're seeing OMPT tests fail on AArch64: libomp :: ompt/misc/control_tool.c libomp :: ompt/synchronization/master.c libomp :: ompt/synchronization/taskwait.c The failure mode is similar for all of them: openmp/runtime/test/ompt/misc/control_tool.c:26:17: error: CHECK-NEXT: expected string not found in input // CHECK-NEXT: {{^}}[[MASTER_ID]]:

Hi, GlobalISel, the SelectionDAG replacement, has come a long way since initially discussed on the mailing list and its last discussion at the EuroLLVM BoF (https://etherpad.net/p/GlobalISel <https://etherpad.net/p/GlobalISel>). We believe we are close to the point of enabling it by default on AArch64 at O0. We now would like to enlist your help to get there. *** Quick Status *** On iOS

Looking through the X86 GlobalISEL code for selecting loads and stores, I'm not seeing the creation of the MachineMemOperands I'd expect to see and do see being generated by SelectionDAG.  Is this simply an oversight, or is there some aspect of the new design which pushes us away from MMOs? Various parts of the machine instruction level optimization passes use the existence and

> On Jan 14, 2017, at 4:57 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 14 January 2017 at 01:54, Quentin Colombet via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL

Curious. I removed -fno-experimental-isel and all of the tests *except* control_tool.c passed. I would have expected all of them to pass if blockaddress works. I'll try to look at some asm and see what's going on. -David Jonas Hahnfeld <hahnjo at hahnjo.de> writes: > Hi David, > > I was the one who originally added the flag to fix failures