search for: mcregisterclass

Looking around today, it appears that TargetRegisterClass and MCRegisterClass only includes a single alignment. This is documented as being the minimum legal alignment, but it appears to often be greater than this in practice. For instance, on x86 the alignment of %ymm0 is listed as 32, not 1. Does anyone know why this is? Additionally, where are these alignments actu...

Hi all, in r152019 (from ctopper), the number of available registers of any type in a machine description is decreased to 256 because it needs to be encoded in uint8_t now. I'm trying to support an experimental embedded architecture with more registers (out of tree), but now that becomes impossible. Anyone knows a solution? Thanks, Bjorn De Sutter Computer Systems Lab Ghent University

I changed it to uint16_t in r152100. Is that enough for your architecture? On Tue, Mar 6, 2012 at 12:24 AM, Bjorn De Sutter < bjorn.desutter at elis.ugent.be> wrote: > Hi all, > > in r152019 (from ctopper), the number of available registers of any type > in a machine description is decreased to 256 because it needs to be encoded > in uint8_t now. I'm trying to support an

...rchitectures without (seemingly, I have no direct experience here) a performance hit. > > - Matthias > >> On Aug 31, 2015, at 3:21 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Looking around today, it appears that TargetRegisterClass and MCRegisterClass only includes a single alignment. This is documented as being the minimum legal alignment, but it appears to often be greater than this in practice. For instance, on x86 the alignment of %ymm0 is listed as 32, not 1. Does anyone know why this is? >> >> Additionally, where are these a...

*** Problem The documentation for function "getSize" in both MCRegisterClass and TargetRegisterClass states: /// getSize - Return the size of the register in bytes, which is also the size /// of a stack slot allocated to hold a spilled copy of this register. The problem is that these two values are not always the same. For example, Hexagon has predicate registers...

...ed what exactly uses it. I thought it was something like that. The AsmPrinter wouldn't need to depend on the XXXMCTargetDesc library, though. It just needs an MCInstrInfo pointer. It already has an MCRegisterInfo pointer. The regIsInRegisterClass() function also looks like it is identical to MCRegisterClass::contains(). It it even used anywhere? /jakob

Hi All, I have a question about TableGen RegisterClass definition. I need to map different size of MVTs into a register class as below. def TestReg : RegisterClass<"Test", [v8i32, v4i32], ...> When I look at TableGen and CodeGen, it looks the types are used as following: 1. MCRegisterClass's RegSize and Alignment 2. SpillSize in TableGen 3. Type constraint for instruction pattern matching >From my opinion, it seems it is possible to do it... but I am not 100% sure... If anyone has information about it, please give me comment. Thanks JinGu Kang Software Engineer Codeplay So...

Is this function required? MCInstrInfo::getName(OpCode) returns the same string, and we have two copies of the string table now. Can MCInstrPrinter refer to MCInstrInfo, and why not? /jakob

On 30.03.2012, at 23:30, Jakob Stoklund Olesen wrote: > Is this function required? > > MCInstrInfo::getName(OpCode) returns the same string, and we have two copies of the string table now. > > Can MCInstrPrinter refer to MCInstrInfo, and why not? I looked into this at some point and if my memory serves me correctly using MCInstrInfo in the printer would create a cyclic

...um of PC range lengths from all DW_TAG_inlined_subroutines referring to that target. This allows the size tool to attribute code size to an inlining target even when the inlined code is not contiguous in the caller. llvm::raw_ostream::operator<<(char const*) [inlining-target] 66720 llvm::MCRegisterClass::contains(unsigned int) const [inlining-target] 64161 llvm::StringRef::StringRef(char const*) [inlining-target] 39262 llvm::MCInst::getOperand(unsigned int) const [inlining-target] 33268 clang::CodeCompletionResult::~CodeCompletionResult() [inlining-target] 25763 llvm::operator+(llvm::Twine...

...om all DW_TAG_inlined_subroutines referring to that target. > This allows the size tool to attribute code size to an inlining target even > when the inlined code is not contiguous in the caller. > > llvm::raw_ostream::operator<<(char const*) [inlining-target] 66720 > llvm::MCRegisterClass::contains(unsigned int) const [inlining-target] 64161 > llvm::StringRef::StringRef(char const*) [inlining-target] 39262 > llvm::MCInst::getOperand(unsigned int) const [inlining-target] 33268 > clang::CodeCompletionResult::~CodeCompletionResult() [inlining-target] 25763 > llvm::o...

...on of the program being compiled. This is different from, for example, floating point rounding mode, which can be changed at run-time. In LLVM, the mode would be determined by subtarget features (reflected in TargetSubtargetInfo). 2. Move the register/spill size and alignment information from MCRegisterClass, and into TargetRegisterInfo. This means that this data will no longer be available to the MC layer. Note that the size/alignment information will be provided by the TargetRegisterInfo object, and not by each individual TargetRegisterClass. A TargetRegisterInfo object would be created for a spe...

...d_subroutines referring to that target. >> This allows the size tool to attribute code size to an inlining target even >> when the inlined code is not contiguous in the caller. >> >> llvm::raw_ostream::operator<<(char const*) [inlining-target] 66720 >> llvm::MCRegisterClass::contains(unsigned int) const [inlining-target] 64161 >> llvm::StringRef::StringRef(char const*) [inlining-target] 39262 >> llvm::MCInst::getOperand(unsigned int) const [inlining-target] 33268 >> clang::CodeCompletionResult::~CodeCompletionResult() [inlining-target] 25763 &g...