Displaying 3 results from an estimated 3 matches for "getbyvaltypealignment".
2015 Mar 09
3
[LLVMdev] byval in a world without pointee types
...ss?)
> then IMO we should keep them on allocas and globals. It keeps the IR human
> readable.
>
& what of byval, then? Do you agree with Chandler's argument from analogy
between byval, alloca, and globals?
(oh, and I should look at inalloca a bit too - it looks like it uses
the getByValTypeAlignment
too... )
- David
>
> We're pretty close to mandatory data layout, so computing the size and
> alignment of these things when they aren't explicitly specified should be
> easy.
>
> On Mon, Mar 9, 2015 at 9:57 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
&g...
2015 Mar 09
2
[LLVMdev] byval in a world without pointee types
...easonable?
>
>
>> I was going to agree - but poking around, it looks like we need alignment
>> too, at least (not sure if we need other things beyond size & alignment,
>> nothing springs to mind but I don't know much about this stuff) -
>> TargetLoweringBase::getByValTypeAlignment/DataLayout::getABITypeAlignment
>>
>
> Nope, we don't, we have an align attribute. =D
>
Yep, seemed the align attribute wasn't always set in the frontend (&
there's a comment in the backend where getByValTypeAlignment is called
saying essentially "this is a fall...
2011 May 06
0
[LLVMdev] Question about linking llvm-mc when porting a new backend
...neInstr const*)in
libLLVMCodeGen.a(RegisterCoalescer.cpp.o)
llvm::CoalescerPair::setRegisters(llvm::MachineInstr const*)in
libLLVMCodeGen.a(RegisterCoalescer.cpp.o)
"llvm::TargetData::getCallFrameTypeAlignment(llvm::Type const*) const",
referenced from:
llvm::TargetLowering::getByValTypeAlignment(llvm::Type const*) constin
libLLVMSelectionDAG.a(TargetLowering.cpp.o)
"llvm::TargetData::getABIIntegerTypeAlignment(unsigned int) const",
referenced from:
llvm::MachineJumpTableInfo::getEntryAlignment(llvm::TargetData const&)
constin libLLVMCodeGen.a(MachineFunction.cpp.o)...