search for: regop

...de "tonezone.h" #include "wctdm.h" static int tones[] = { ZT_TONE_DIALTONE, ZT_TONE_BUSY, ZT_TONE_RINGTONE, ZT_TONE_CONGESTION, ZT_TONE_DIALRECALL, }; int main(int argc, char *argv[]) { ZT_DIAL_OPERATION dop; struct wctdm_regop regop; struct zt_dialparams dps; int fd,ctlfd,toneduration; int res; int x; if (argc < 3) { fprintf(stderr, "Usage: fxstest <zap device> <cmd>\n" " where cmd is one of:\n"...

...dea what to do the work-around. To me the modifier is set when the register has absolute or negate. I traced the code and thought that the problem occurs in the for loop to empty the modifiers for each source (in the AMDGPUAsmParser::parseOperand around line 1040). If I add an if statement like if(RegOp.isInlineImm()) // because 0.5 is this case contiune; before the statement to empty the modifier (RegOp.setModifiers(0);), it obvious does not work and cause the other matching fails. Does it mean to modify other files in other places, such as the VOP3Inst in the SIInstrInfo.td, or is this not...

...onfused about what the following code in CompileUnit::constructVariableDIE is trying to do: if (const MachineInstr *DVInsn = DV->getMInsn()) { bool updated = false; if (DVInsn->getNumOperands() == 3) { if (DVInsn->getOperand(0).isReg()) { const MachineOperand RegOp = DVInsn->getOperand(0); const TargetRegisterInfo *TRI = Asm->TM.getRegisterInfo(); if (DVInsn->getOperand(1).isImm() && TRI->getFrameRegister(*Asm->MF) == RegOp.getReg()) { unsigned FrameReg = 0; const TargetFrameLowering...

On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: > I'm investigating a bug associated with debug information that manifests > itself in the XCore backend (PR11105). I'd like to understand what the > expected behavior of eliminateFrameIndex() is when it is called on a > dbg_value machine instruction. That is up to the target. The TII::emitFrameIndexDebugValue() hook is

I'm investigating a bug associated with debug information that manifests itself in the XCore backend (PR11105). I'd like to understand what the expected behavior of eliminateFrameIndex() is when it is called on a dbg_value machine instruction. Currently the XCore target replaces the frame index with the frame register and sets the next operand to the byte offset from the frame

...MachineInstr *MI) const { But down in the code we have this: if (TargetRegisterInfo::isPhysicalRegister(Reg) && !allocatableRegs_[Reg]) continue; // FIXME: For now, only remat MI with at most one register operand. assert(!RegOp && "Can't rematerialize instruction with multiple register operand!"); RegOp = MO.getReg(); #ifndef NDEBUG break; #endif So if Reg is an allocatable physical register, it gets returned as an implicit use. This directly contradicts the comment when talks ab...

Dear Developers, I compile a OpenCL kernel, FFT, in AMDAPP SDK v2.5 using clang 3.8 + libclc and assembling the code with lld (The LLVM linker). The assembly code contains the following assembly codes (and lots of other similar format assembly) that fails to be parsed by AMDGPUAsmParser. It seems to me that both are valid instructions after looking at the SI instruction spec. s_mov_b32 s0,

...peration. I see that the RegisterClass has a list of ValueTypes, and I conclude that I can define a register class to use for the mixed operands that has both integer and floating point valuetypes. I would like to do: reg:IntRC = IntegerOp... ~or~ reg:FloatRC = FloatOp ... ... consumingMI regOp:MixedRC IntRC = [i32], "reg1,...", FloatRC = [f32], "reg1, ...", MixedRC = [i32, f32], "reg1, ...". Does this approach seem fair? What are the consequences in the backend for the different value types for operands? /Jonas -------------- next part -----...

Hello, In my system, dmesg outputs : [ 13.039788] wcb4xxp 0000:01:0a.0: probe called for b4xx... [ 13.039788] ACPI: PCI Interrupt 0000:01:0a.0[A] -> GSI 21 (level, low) -> IRQ 21 [ 13.039788] wcb4xxp 0000:01:0a.0: Identified HFC-8S Junghanns.NET octoBRI PCI (controller rev 1) at 0001dfe0, IRQ 21 [ 13.041202] wcb4xxp 0000:01:0a.0: NOTE: hardware echo cancellation has been disabled [

Roman Levenstein wrote: > Hi again, > > Now, after I fixed the graph coloring regalloc bug that was triggered > by the ARM target, I continue testing and found another bug, this time > on the XCore target. First I thought that it is again specific to my > register allocator, but it seems to be trigerred also by LLVM's > linearscan register allocator. > > I don't

...g copy) @@ -820,6 +820,9 @@ > unsigned Reg = MO.getReg(); if (Reg == 0 || Reg == li.reg) continue; > + if (TargetRegisterInfo::isPhysicalRegister(Reg) && + ! > allocatableRegs_[Reg]) + continue; // FIXME: For now, only remat MI > with at most one register operand. assert(!RegOp && "Can't > rematerialize instruction with multiple register operand!"); > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmd...

Hi again, Now, after I fixed the graph coloring regalloc bug that was triggered by the ARM target, I continue testing and found another bug, this time on the XCore target. First I thought that it is again specific to my register allocator, but it seems to be trigerred also by LLVM's linearscan register allocator. I don't know if the XCore target is stable enough in LLVM, or may be I