search for: framelow

...1029e3c 100644 --- a/lib/Target/Mips/CMakeLists.txt +++ b/lib/Target/Mips/CMakeLists.txt @@ -32,6 +32,8 @@ add_llvm_target(MipsCodeGen MipsLongBranch.cpp MipsMCInstLower.cpp MipsMachineFunction.cpp + MipsModuleISelDAGToDAG.cpp + MipsModuleISelLowering.cpp MipsRegisterInfo.cpp MipsSEFrameLowering.cpp MipsSEInstrInfo.cpp diff --git a/lib/Target/Mips/Mips16ISelDAGToDAG.cpp b/lib/Target/Mips/Mips16ISelDAGToDAG.cpp index 00b3449..2ffd3a9 100644 --- a/lib/Target/Mips/Mips16ISelDAGToDAG.cpp +++ b/lib/Target/Mips/Mips16ISelDAGToDAG.cpp @@ -35,6 +35,11 @@ #include "llvm/Target/TargetM...

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

I'm just getting started changing the emitted code. Suppose I want to just add one new instruction to the function prologue at the top. Where would I do this? Does it depend on the backend? I'm targeting RISCV64. Gry

...I would like to know in order to support exception handling for particular target, what need to be done. After doing some investigation, I can think of the following items with questions: - CFI directives: This is for .eh_frame section. Basically all the targets insert CFI directives in FrameLowering, but I am not sure exactly when/where I should do so. - getExceptionPointerRegister and getExceptionSelectorRegister: TargetLowering subclass should implement both functions. The former specifies the register used to pass the exception object to the landing pad (or catch clause), and t...

On 15 January 2018 at 12:49, 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > - CFI directives: > > This is for .eh_frame section. Basically all the targets insert CFI > directives in FrameLowering, but I am not sure exactly when/where I should > do so. The directives are there to describe where the unwinder should look to find out what each register's value was when this function was called (well, each register that the caller expected to be preserved). So the directives have to...

...e of load/store haflword and byte to stack objects. >> > > ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. > > If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. > >> Maybe I'm shooting myself in the foot there. I don't know that code too well so maybe I need...

...in this case of load/store haflword and byte to stack objects. > ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. > Maybe I'm shooting myself in the foot there. I don't know that code too well so maybe I need to look into it....

...e haflword and byte to stack objects. >>> >> >> ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. >> >> If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. >> >>> Maybe I'm shooting myself in the foot there. I don't know that code too we...

...y > clobbered set of registers up the callgraph instead of relying on > conventions, so it is best to aim for more caller saved registers (though > we should check for code size increases and store/restore code being > potentially less good than the tuned sequences generated during > FrameLowering). > > To the disucssion at hand: > - Introducing a new calling convention at the IR level is the wrong > approach: The calling convention is mostly a contract when calling and > being called across translation unit boundaries. The details about how this > contract is fulfille...

Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. Maybe I'm shooting myself in the foot there. I don't know that code too well so maybe I need to look into it. There are

...nd though it's unlikely we'd like 0x80000000 to be interpreted as positive, rather than negative if it ever does occur. Also, CreateFixedObject seems to take an int64_t I'd suggest: + ISelLowering line 2459: cast FPDiff to int64_t. + ISelLowering line 3327: cast SlotSize to int64_t. + FrameLowering: declare TailCallReturnAddrDelta as int64_t and subtract SlotSize? It would also be really good if you could convert your IR into a test-case (like the others in "test/CodeGen/X86/"). We like to have a test-case for every commit if it's humanly possible. Cheers. Tim.

...and byte to stack objects. >>>> >>> >>> ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. >>> >>> If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. >>> >>>> Maybe I'm shooting myself in the foot there. I don't know th...

Dear LLVM developers, I am a developer of SML#, an ML-style functional programming language developed at Tohoku University. Currently we are intending to use LLVM as the backend of our SML# compiler in our upcoming release, and have rewritten our frontend and runtime so that they can cooperate with LLVM. LLVM works extremely fine with our SML# compiler. We are grateful to LLVM community for

...8:00 Tim Northover <t.p.northover at gmail.com>: > On 15 January 2018 at 12:49, 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > - CFI directives: > > > > This is for .eh_frame section. Basically all the targets insert CFI > > directives in FrameLowering, but I am not sure exactly when/where I > should > > do so. > > The directives are there to describe where the unwinder should look to > find out what each register's value was when this function was called > (well, each register that the caller expected to be preserve...

...ameters should be passed or any special rule for return value etc , it just required to set callee saved registers to be none. So what are the minimal things required to define such a CC? Other alternative that I have thought was to add new attribute for function and use it like following in TargetFrameLowering::determineCalleeSaves() // In Naked functions we aren't going to save any registers. if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) return; Any suggestions / thoughts are welcomed ! Sincerely, Vivek -------------- next part -------------- An HTML attachment was scrubb...

...U/AMDILDevices.h > llvm/trunk/lib/Target/AMDGPU/AMDILEnumeratedTypes.td > llvm/trunk/lib/Target/AMDGPU/AMDILEvergreenDevice.cpp > llvm/trunk/lib/Target/AMDGPU/AMDILEvergreenDevice.h > llvm/trunk/lib/Target/AMDGPU/AMDILFormats.td > llvm/trunk/lib/Target/AMDGPU/AMDILFrameLowering.cpp > llvm/trunk/lib/Target/AMDGPU/AMDILFrameLowering.h > llvm/trunk/lib/Target/AMDGPU/AMDILISelDAGToDAG.cpp > llvm/trunk/lib/Target/AMDGPU/AMDILISelLowering.cpp > llvm/trunk/lib/Target/AMDGPU/AMDILISelLowering.h > llvm/trunk/lib/Target/AMDGPU/AMDILInstrInfo....