Problem with memory alignment for 64 byte moves
Hello everyone. I'm porting gcc to a new architecture and I'm allowing use of movdi instructions as the processor allows 8 byte loads. The processor however requires 8 byte loads and stores to be naturally aligned, yet gcc seems to be emitting loads and stores that are 4 byte aligned. How can I make sure that gcc will only emit 8 byte loads and stores if it knows the address, which can be in a register, is 8 byte aligned?
Re: Problem with memory alignment for 64 byte moves
Hi Ian Thanks for the response. All of those flags are set correctly, though it is still emitting loads and stores 4 byte aligned and not 8. I'm trying to get the compiler to combine two 4 byte loads in to a single 8 byte load as it is more efficient on this architecture, so I'm guessing because the objects being loaded are actually 4 byte aligned, the compiler is matching for this alignment. There was a similar email about combining loads/stores which people seemed to suggest wasn't possible. Is there any way to do this other than writing a machine reorg pass which will split up loads and stores it notices are misaligned? On 3 December 2010 19:34, Ian Lance Taylor wrote: > Neil Hickey writes: > >> I'm porting gcc to a new architecture and I'm allowing use of movdi >> instructions as the processor allows 8 byte loads. The processor >> however requires 8 byte loads and stores to be naturally aligned, yet >> gcc seems to be emitting loads and stores that are 4 byte aligned. How >> can I make sure that gcc will only emit 8 byte loads and stores if it >> knows the address, which can be in a register, is 8 byte aligned? > > Define STRICT_ALIGNMENT to 1. > > Make sure that BIGGEST_ALIGNMENT, BIGGEST_FIELD_ALIGNMENT, > MAX_STACK_ALIGNMENT, DATA_ALIGNMENT, etc. are correct. > > Ian >
Question about long jump implementation
I'm trying to implement long jump and I'm using the call instruction
in the arm implementation as a reference.
The code looks like this:
rtx callee, pat;
callee = XEXP(operands[0], 0);
if (GET_CODE (callee) == SYMBOL_REF
? atdsp_is_long_call_p (SYMBOL_REF_DECL (callee))
: !REG_P (callee)) {
XEXP(operands[0], 0) = force_reg (SImode, callee);
}
pat = gen_call_internal (operands[0], operands[1]);
emit_call_insn(pat);
DONE;
What I want to happen is for the function name to be copied to a
register and then the compiler emit the instruction to call the
function, by jumping to the address held in that register.
The compiler emits instructions that copy the function name to a
register, then it loads from the value of this register, before
jumping to the loaded value. What I want it to do is copy the function
name to the register, then jump to the address held in this register.
Does anyone know what it is I've done wrong and how I can get this to work?
Thanks
Neil
Re: Question about long jump implementation
Hi Ian, thanks for the response.
I did manage to fix it. The problem was in my call_internal
implementation. I went back and looked again at the arm implementation
and spotted what I'd done wrong.
Sorry for the bother.
On 17 December 2010 01:21, Ian Lance Taylor wrote:
> Neil Hickey writes:
>
>> I'm trying to implement long jump and I'm using the call instruction
>> in the arm implementation as a reference.
>>
>> The code looks like this:
>>
>> rtx callee, pat;
>>
>> callee = XEXP(operands[0], 0);
>> if (GET_CODE (callee) == SYMBOL_REF
>> ? atdsp_is_long_call_p (SYMBOL_REF_DECL (callee))
>> : !REG_P (callee)) {
>> XEXP(operands[0], 0) = force_reg (SImode, callee);
>> }
>> pat = gen_call_internal (operands[0], operands[1]);
>> emit_call_insn(pat);
>> DONE;
>>
>> What I want to happen is for the function name to be copied to a
>> register and then the compiler emit the instruction to call the
>> function, by jumping to the address held in that register.
>>
>> The compiler emits instructions that copy the function name to a
>> register, then it loads from the value of this register, before
>> jumping to the loaded value. What I want it to do is copy the function
>> name to the register, then jump to the address held in this register.
>>
>> Does anyone know what it is I've done wrong and how I can get this to work?
>
> I think it's impossible for us to say without more information.
>
> Does the RTL look correct? If not, then you need to fix the RTL
> generation, which will look more or less like the code above. If the
> RTL does look correct, then you need to fix your MD file to generate
> instructions which correctly represent the RTL.
>
> Ian
>
