search for: frameinfo

...--------------------------- Type       | struct elements                      | Size in bytes | Correct size in bytes -------------------------------------------------------------------------------------------- short          nScaleFactors                               4            2 FRAME_INFO     frameInfo                                  36           36 short          domain_vec[MAX_ENVELOPES]                  10           10 short          domain_vec_noise[MAX_NOISE_ENVELOPES]       6            4 INVF_MODE      sbr_invf_mode[MAX_INVF_BANDS]              20           20 COUPLING_MODE  coupling     ...

...s offset calculation for the struct elements (described earlier).   Type Variable Actual Size(in bytes) pass fail llvm2.9 Address(pass) Size-pass (in bytes) Address (fail) Size -fail (in bytes) with llvm2.9 Size (with llvm2.9) short  nScaleFactors;  2 40ac0198 4 40ac0198 2 40ac0190 2 FRAME_INFO  frameInfo; //struct described below 34 40ac019c 36 40ac019a 36 40ac0192 36 short  domain_vec[MAX_ENVELOPES];  10 40ac01c0 10 40ac01be 10 40ac01b6 10 short  domain_vec_noise[MAX_NOISE_ENVELOPES];  4 40ac01ca 6 40ac01c8 4 40ac01c0 4 INVF_MODE  sbr_invf_mode[MAX_INVF_BANDS];  20 40ac01d0 20 40ac01cc 20 40ac0...

Hi, I'm looking for some pointers on how to troubleshoot this problem. I'm trying to write a backend for the AVR. There is an undefined reference at line 48 which is the line FrameInfo() is on. I've tried to use the MSP430 and other targets as references so I'm not sure what changes I did would cause a problem on this line? AVRTargetMachine::AVRTargetMachine(const Target &T, const std::string &TT, const std::string &FS)...

With reference to the previous query, I think, i miscalculated the offset, just recalculating. 1. without instruction combining coupling member variable, is at:   %struct._FRAME_DATA* %2, i32 0, i32 5   where "%2" is defined as:   %arrayidx3 = getelementptr inbounds i16* %Data, i32 1024, !dbg !446   %2 = bitcast i16* %arrayidx3 to %struct._FRAME_DATA*, !dbg !446 i.e. at 5 offset in

...-------------------------------------------------------------------------------------- > Type | struct elements | Size in bytes | Correct size in bytes > -------------------------------------------------------------------------------------------- > short nScaleFactors *4 2 > *FRAME_INFO frameInfo 36 36 > short domain_vec[MAX_ENVELOPES] 10 10 > short domain_vec_noise[MAX_NOISE_ENVELOPES] 6 4 > INVF_MODE sbr_invf_mode[MAX_INVF_BANDS] 20 20 > COUPLING_MODE coupling 4 4 > short ampResolutionCurrentFrame 2 2 > Flag addHarmonics[MAX_FREQ_COEFFS] 192 192 > short maxQmfSubbandA...

Hello, John > There is an undefined reference at line 48 which is the line FrameInfo() is > on. I've tried to use the MSP430 and other targets as references so I'm not > sure > what changes I did would cause a problem on this line? It doesn't seem you're linking libTarget in. Have you tried not to use cmake-generated makefiles? As for the cmake - it tracked...

...eInstrs (i.e., native code instructions generated from the LLVM IR instructions). The runOnMachineFunction() method is its entry point (i.e., the code generator calls runOnMachineFunction() for each MachineFunctionPass that it runs. > In my experimentation it didn't seem that the MachineFrameInfo was > populated (it consistently said that the stack depth was 0, for > example). I might have been doing something wrong? Is it possible that the function being compiled had a zero-sized stack frame? If it has no spill slots or alloca instructions, and if the function parameters are no...

John Myers <atomicdog.jwm at gmail.com> writes: > I'm looking for some pointers on how to troubleshoot this problem. I'm > trying to write a backend for the AVR. > There is an undefined reference at line 48 which is the line FrameInfo() is > on. I've tried to use the MSP430 and other targets as references so I'm not > sure > what changes I did would cause a problem on this line? cmake tracks library dependencies on $LLVM_ROOT/cmake/modules/LLVMLibDeps.txt That file is automatically updated on Unix and Unix-lik...

...2, i32* %1, align 4 %9 = mul nsw i32 %7, %8 br label %10 ; <label>:10 ; preds = %0, %4 %11 = phi i32 [ %9, %4 ], [ 1, %0 ] ret i32 %11 } ... --- number: 0 name: fact alignment: 4 regInfo: .... frameInfo: .... body: - bb: 0 llbb: '%0' successors: [ 'bb#2', 'bb#1' ] liveIns: [ '%edi' ] instructions: - 'push64r undef %rax, %rsp, %rsp' - 'mov32mr %rsp, 1, %noreg, 4, %noreg, %edi...

I investigated the MachineFunctionPass (that is runOnMachineFunction, I believe). In my experimentation it didn't seem that the MachineFrameInfo was populated (it consistently said that the stack depth was 0, for example). I might have been doing something wrong? On Fri, Jul 8, 2011 at 5:21 PM, John Criswell <criswell at illinois.edu> wrote: > On 7/8/11 4:09 PM, Andrew Ruef wrote: > > Hi list, > > I am trying to imp...

The X86 backend has this code: X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering *IL) : .... FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4), That is, it uses "4" as local area offset. Based on prior discussion this should mean that the local area starts and address ESP+4. Is this really true? On X86 stack grows down, so I'd expect local area to start below ESP, e.g....

...; preds = %0, %4 > > %11 = phi i32 [ %9, %4 ], [ 1, %0 ] > > ret i32 %11 > > } > > > ... > > --- > > number: 0 > > name: fact > > alignment: 4 > > regInfo: > > .... > > frameInfo: > > .... > > body: > > - bb: 0 > > llbb: '%0' > > successors: [ 'bb#2', 'bb#1' ] > > liveIns: [ '%edi' ] > > instructions: > > - 'push64r undef %rax, %...

...gt;> >>> >>> ... >>> >>> --- >>> >>> number: 0 >>> >>> name: fact >>> >>> alignment: 4 >>> >>> regInfo: >>> >>> .... >>> >>> frameInfo: >>> >>> .... >>> >>> body: >>> >>> - bb: 0 >>> >>> llbb: '%0' >>> >>> successors: [ 'bb#2', 'bb#1' ] >>> >>> liveIns:...

On Wed, 9 Jun 2004, Vladimir Prus wrote: > > The X86 backend has this code: > > X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering *IL) > : .... > FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4), > > That is, it uses "4" as local area offset. Based on prior discussion this > should mean that the local area starts and address ESP+4. Is this really > true? On X86 stack grows down, so I'd expect local area to start...

...k then. For my target, the stack should be aligned even for leaf functions. In particular, hardware interrupt can arrive at any time, and stack should be 8-byte aligned at the time of interrupt, otherwise things will break. I can address this issue by using two tricks together: 1. Calling MachineFrameInfo::setHasCalls in my backend 2. Using the attached patch, so that value of setHasCalls is not reset to false later. Comments? BTW, I've checked other uses of MachineFrameInfo::hasCalls. For example, PPCRegisterInfo uses it to check if if callee save registers can be stored in something called...

...i16* %timeData, i32 1060, !dbg !575   %24 = bitcast i16* %coupling to i32*, !dbg !575   store i32 0, i32* %24, align 4, !dbg !575     The FRAME_DATA, is defined as: typedef struct _FRAME_DATA {   Word16 nScaleFactors;                    /*!< total number of scalefactors in frame */   FRAME_INFO frameInfo;                 /*!< time grid for current frame */   Word16 domain_vec[MAX_ENVELOPES];  /*!< Bitfield containing direction of delta-coding for each envelope */   Word16 domain_vec_noise[MAX_NOISE_ENVELOPES]; /*!< Same as above, but for noise envelopes */   INVF_MODE sbr_invf_mode[MAX_INV...

Paolo Invernizzi wrote: > There was a similar problem some time ago, and was resolved with alloca. > I think it's a better solution to use the stack instead of the heap... I tend to agree, but the constructors won't get called if it's an object array -- anyway, this particular case there was no objects, just pointers and bools so alloca should be fine. I'll leave it to

...; preds = %0, %4 > > %11 = phi i32 [ %9, %4 ], [ 1, %0 ] > > ret i32 %11 > > } > > > ... > > --- > > number: 0 > > name: fact > > alignment: 4 > > regInfo: > > .... > > frameInfo: > > .... > > body: > > - bb: 0 > > llbb: '%0' > > successors: [ 'bb#2', 'bb#1' ] > > liveIns: [ '%edi' ] > > instructions: > > - 'push64r undef %rax, %...