I'm still trying to track down some alignment issues with loads(i.e. 8/16 bit loads being turned into 32bit sign extending loads) and I cannot for the life of me seem to figure out how to enter this section of code: // If this is an unaligned load and the target doesn't support it, // expand it. if (!TLI.allowsUnalignedMemoryAccesses()) { unsigned ABIAlignment = TLI.getTargetData()-> getABITypeAlignment(LD->getMemoryVT().getTypeForMVT()); if (LD->getAlignment() < ABIAlignment){ Result ExpandUnalignedLoad(cast<LoadSDNode>(Result.getNode()), DAG, TLI); Tmp1 = Result.getOperand(0); Tmp2 = Result.getOperand(1); Tmp1 = LegalizeOp(Tmp1); Tmp2 = LegalizeOp(Tmp2); } } This is from LegalizeDAG.cpp:2146 The problem that I see is that LD->getAlignment() is set via the call getMVTAlignment(VT) in SelectionDAG.cpp:3385, which in turn calls TLI.getTargetData()->getABITypeAlignment(Ty). So, the statement if (LD->getALignment() < ABIAlignment) always fails from what I can see. Even if I set in my DataLayout that i8 should have a 32bit ABI alignment, this does not work because the load alignment is set to the ABI alignment instead of being set based on the actual bit size. Any hints would be greatly appreciated, this is a blocking issue that I just cannot seem to resolve without modifying the LLVM codebase to remove the extend + load -> extload combining step. Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-749-3966 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090218/2d66731f/attachment.html>
On Wed, Feb 18, 2009 at 10:14 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote:> I'm still trying to track down some alignment issues with loads(i.e. 8/16 > bit loads being turned into 32bit sign extending loads) and I cannot for the > life of me seem to figure out how to enter this section of code: > > // If this is an unaligned load and the target doesn't support it, > > // expand it.Why do you expect to enter this section of code? It's impossible for an i8 load to be unaligned.> Any hints would be greatly appreciated, this is a blocking issue that I just > cannot seem to resolve without modifying the LLVM codebase to remove the > extend + load -> extload combining step.LLVM will "uncombine" it for you if you use setLoadExtAction with the appropriate arguments. -Eli
-----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Wednesday, February 18, 2009 3:01 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Possible error in LegalizeDAG On Wed, Feb 18, 2009 at 10:14 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote:> I'm still trying to track down some alignment issues with loads(i.e.8/16> bit loads being turned into 32bit sign extending loads) and I cannotfor the> life of me seem to figure out how to enter this section of code: > > // If this is an unaligned load and the target doesn't support it, > > // expand it.>Why do you expect to enter this section of code? It's impossible for >an i8 load to be unaligned.On the hardware that I am targeting, which is not a CPU, I must support i8 loads, however the hardware only supports natively 32bit aligned loads, therefore I have to read in 4 i8's and unpack them and shift them based on the read address. So any i8 load has a 75% chance of being unaligned on my hardware, so I need a way to tell LLVM not to generate sext_loads, or if it does to expand them. Everything that has been suggested so far has not worked.> Any hints would be greatly appreciated, this is a blocking issue thatI just> cannot seem to resolve without modifying the LLVM codebase to removethe> extend + load -> extload combining step.>LLVM will "uncombine" it for you if you use setLoadExtAction with the >appropriate arguments.>-EliI've tried setting setLoadXAction to Custom, Legal, Expand and Promote. I assert somewhere when I try to custom expanding this operation because it expects it to be a certain form, but my custom load instruction has a different form. Setting it to Legal generates the sext_load in the first dag combine pass, because it never checks if it should make this combination. Since it doesn't enter the section of code I mentioned earlier, it never uncombines it. When I set it to promote, it asserts on "not yet implemented". Setting it to Expand does not expand it to sign_extend and load but to extload and sign_extend, but I don't support extload either. Please correct me if I am wrong, but I've been looking at this issue for awhile now and I cannot see where it uncombines the sextload to a load and sign_extension. My current solution is to just comment out that combination so that it never occurs. Thanks, Micah
Apparently Analagous Threads
- [LLVMdev] Possible error in LegalizeDAG
- [LLVMdev] Possible error in LegalizeDAG
- [LLVMdev] Possible error in LegalizeDAG
- [LLVMdev] ReduceLoadWidth, DAGCombiner and non 8bit loads/extloads question.
- [LLVMdev] ReduceLoadWidth, DAGCombiner and non 8bit loads/extloads question.