search for: extload

...on which >> TargetLowering callback method we use. For example, Custom will let it >> through to instructions selection, which it breaks at the that phase, >> otherwise I believe it breaks during legalization. If we use Expand instead, >> the assert during Legalize is: "EXTLOAD should always be supported". I don't >> really understand that message :) > > Keep in mind "EXTLOAD" usually means "load, possibly followed by an > extension". So, the "EXT" part is probably irrelevant here, if that's > what's buggin...

On Wed, Mar 4, 2015 at 11:43 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Ahmed, > > Yes, we do not have an 8 bit type and do not support 8 bit loads/extloads. > > For your first post, I imagine that anything that the DAGCombiner does it > could undo EXCEPT deciding to opt to a type that is not allowed, No, I think the SelectionDAG legalization should be able to "undo" any illegal type as well. For loads/stores, this usually means...

Hi Chandler, all, Why aren't the vector [zs]extloads introduced by SSE4.1/AVX2 declared legal? Is it a simple oversight, or did I miss a deeper reason? While cleaning up PMOV*X patterns, I stumbled upon this braindead testcase: %0 = load <8 x i8>* %src, align 1 %1 = zext <8 x i8> %0 to <8 x i16> turning into:...

...t 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 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 I've tried setting setLoadXAction to Custom, Legal, Expand and Promote. I assert somewhere when I try to custom expanding this operation because it expects...

...t them > based on the read address. So any i8 load has a 75% chance of being > unaligned on my hardware, Oh, okay, makes sense. > I've tried setting setLoadXAction to Custom, Legal, Expand and Promote. > 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. I suppose you could consider that a bug. That said, why is this difficult to implement? You can just treat an extload of an i8 as a load of an i8 and get correct code, no? -Eli

...uring the legalize phase, depending on which TargetLowering callback method we use. For example, Custom will let it through to instructions selection, which it breaks at the that phase, otherwise I believe it breaks during legalization. If we use Expand instead, the assert during Legalize is: "EXTLOAD should always be supported". I don't really understand that message :) The pre-legalization canonicalization makes sense to me but either 1) legalize should be able to handle everything or 2) nodes that aren't going to be legal anyways should not be produced (though this obviously co...

...t seem good to generate something pre-legalize (target-independent) that you can't then handle when you find that it's illegal in the very next step that is legalization. I'm guessing, from what you and others have said, that it's just expected that every machine will support 8-bit extloads and if not then the target should handle the undoing of the target-independent generated 'optimization' via LegalizeDAG and TargetLowering callback methods? 3) I have not tried running it on any other target, sorry, I suppose I should but I didn't want to take the time if I'm not...

...xygen/html/classllvm_1_1SDValue.html>(); LegalOperations is false for the first pre-legalize pass and true for the post-legalize pass. The first pass is target-independent yes? So that makes sense. The issue we are having is this: we don't support 8 bit loads and we don't support 8 bit extloads, so we end up with LD1 with zext after either the first pass or the second pass (depending on the test case). If we add the TargetLowering callback method setLoadExtAction(ISD::ZEXTLOAD, MVT::i8, Expand) then it crashes during legalization and if we don't have that in then it crashes during in...

...s 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/piper...

On Thu, Mar 5, 2015 at 4:19 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Thanks for the reply: > > So should LLVM continue to assume 8-bit byte addressing? It would be nice, > not only to us but potential future machines, to have a permanent fix to > this assumption? This sounds reasonable yes? > > Marking them as Custom in XXXISelLowering still produces error, the

...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

...less than 8bit on "DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT" like this roughly. if (N->getOperand(0).getValueType().getVectorElementType().getSizeInBits() < 8) { return DAG.getLoad(N->getValueType(0), dl, Store, StackPtr, MachinePointerInfo()); } else { return DAG.getExtLoad(ISD::EXTLOAD, dl, N->getValueType(0), Store, StackPtr, MachinePointerInfo(), EltVT); } How do you think about it? Thanks, JinGu Kang On 15/09/2017 18:42, Demikhovsky, Elena wrote: extends the elements to 8bit and stores them on stack. Store is responsible for zero-extend. This is the policy...

...quot;DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT" like this roughly. > if (N->getOperand(0).getValueType().getVectorElementType().getSizeInBits() < 8) { > return DAG.getLoad(N->getValueType(0), dl, Store, StackPtr, MachinePointerInfo()); > } else { > return DAG.getExtLoad(ISD::EXTLOAD, dl, N->getValueType(0), Store, StackPtr, MachinePointerInfo(), EltVT); > } I assume that we need the opposite - if (.. < 8) getExtLoad // VT should be MVT::i8, MemVT should be MVT::i1 else getLoad - Elena From: jingu at codeplay.com [mailto:jingu at codeplay....

...ed by armv2a, so I need to make the code generation to not generate ldrh instructions. I want to replace all those instances with a 32-bit load (ldr) and then and the result with 0xffff to mask out the upper bits. These are the modifications that I have made to accomplish that: 1. Register the ZEXTLOAD for custom lowering: setLoadExtAction(ISD::ZEXTLOAD, MVT::i16, Custom); 2. Implement a custom lowering function: static SDValue LowerExtLoad(SDValue Op, SelectionDAG &DAG) { LoadSDNode *LD = dyn_cast<LoadSDNode>(Op.getNode()); ISD::LoadExtType ExtType = LD->getExtensionType();...

...t13, t15" because t13's > result type is 'v2i1'. If the size of vector element is less than > 8bit, 'DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT()' function > extends the elements to 8bit and stores them on stack. Finally, the > function generates 'ExtLoad' to load specific element. But if the > element's size is less than 8bit, I think it could be wrong. It looks > it needs just 'Load' or "Load and Truncate" to match the result type > of 'EXTRACT_VECTOR_ELT'. How do you think about it? If I missed >...

...it should be a goal of the new framework to make this a bit easier. +1 Do you and/or Adrian also have thought on testing debug values? Verification and testing strategies should/could be part of the design also. > > best, > vedant > > [1] To pick one at random, the '(zext (zextload x)) -> (zext (truncate (zextload x)))' combine should transfer debug values from N to the new ExtLoad, and from N0 to the new (trunc ExtLoad), but currently doesn't. > >> >> Thanks, >> Amara >> _______________________________________________ >> LLVM Dev...

...= extract_vector_elt t13, t15" because t13's result type is 'v2i1'. If the size of vector element is less than 8bit, 'DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT()' function extends the elements to 8bit and stores them on stack. Finally, the function generates 'ExtLoad' to load specific element. But if the element's size is less than 8bit, I think it could be wrong. It looks it needs just 'Load' or "Load and Truncate" to match the result type of 'EXTRACT_VECTOR_ELT'. How do you think about it? If I missed something, please le...

...> > --- > > Adrian and others have thought about these issues much more, so take these ideas with a grain of salt :). > > thanks, > vedant > > >>> >>> best, >>> vedant >>> >>> [1] To pick one at random, the '(zext (zextload x)) -> (zext (truncate (zextload x)))' combine should transfer debug values from N to the new ExtLoad, and from N0 to the new (trunc ExtLoad), but currently doesn't. >>> >>>> >>>> Thanks, >>>> Amara >>>> _________________________...

...i32,ch = load 0x17faa00, 0x17fac00, >>> 0x17f6a70<LD2[%arrayidx4+2], zext from i16> >>> >>> That seems like a logical thing to do on a lot of targets, but in my >>> case, the LD4->SRL combo was emitted precisely because I *don't* want a >>> ZEXTLOAD i16.  I'm wondering if there is: >>> >>> a) A way to turn off this optimization in DAGCombine if your target >>> doesn't support LD2 natively >> >> This. >> >> I think you're talking about DAGCombiner::ReduceLoadWidth... and the >&gt...

...VR::SREG, MVT::i8); // Disable interrupts (`clr` is equivalent to `bclr 7`). auto ClearInterrupts = DAG.getNode(AVRISD::BCLR, DL, MVT::Glue, DAG.getConstant(7, DL, MVT::i8)); // Perform the nonatomic load. auto *Node = cast<AtomicSDNode>(AtomicOp.getNode()); SDValue Load = DAG.getExtLoad(ISD::EXTLOAD, SDLoc(AtomicOp), AtomicOp.getValueType(), Node->getChain(), Node->getBasePtr(), Node->getMemoryVT(), Node->getMemOperand()); auto Restore = DAG.getCopyToReg(DAG.getEntryNode(), DL, AVR::SREG, Save); re...