HI Guys, I have a “normal” load instruction like the following: " %2 = load i16 addressspace(1) * %1, align 2, !tbaa !10 “ where the metadata tbaa is telling me that the source is a signed short. So I want to do a “signed load” when I am lowering the Load operation.( LLVM now just tells me “load i16” without any sign or unsign info) questions: (1) How could I pass the “sign” flag to customLowering? (2) I wanted to “trick” llvm by “ inserting an extend, and followed by an truncate” instructions, so I am hoping that LLVM can send me a “SextLoad” and “Truncate”. But LLVM is smart enough, it just ignores my effort. Is there anyway to “workaround” this problem? best kevin
> On Jul 9, 2015, at 12:54 PM, kewuzhang <kewu.zhang at amd.com> wrote: > > HI Guys, > > I have a “normal” load instruction like the following: > " > %2 = load i16 addressspace(1) * %1, align 2, !tbaa !10 > “ > where the metadata tbaa is telling me that the source is a signed short. > So I want to do a “signed load” when I am lowering the Load operation.( LLVM now just tells me “load i16” without any sign or unsign info)This isn’t want the TBAA metadata is for. You shouldn’t be trying to decide if a type is signed or not, especially not using metadata which is likely to not be present. If a load is used in a sign extended way, the DAG node will report that it’s extension type is SEXTLOAD by the time it reaches the custom lowering. You should not be concerned with the C type this happens to correspond to, only the specific load operation the target is asked to handle.> > questions: > (1) How could I pass the “sign” flag to customLowering?You should only be checking if a load is a sextload.> > (2) I wanted to “trick” llvm by “ inserting an extend, and followed by an truncate” instructions, so I am hoping that LLVM can send me a “SextLoad” and “Truncate”. > But LLVM is smart enough, it just ignores my effort. > > Is there anyway to “workaround” this problem? > > best > kevinIf you really want to hack around folding conversions, you would need to insert a new node type / target node that the DAG combiner doesn’t understand -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150709/dd0a5f55/attachment.html>
On 7/9/2015 2:54 PM, kewuzhang wrote:> > I have a “normal” load instruction like the following: > " > %2 = load i16 addressspace(1) * %1, align 2, !tbaa !10 > “ > where the metadata tbaa is telling me that the source is a signed short. > So I want to do a “signed load” when I am lowering the Load operation.( LLVM now just tells me “load i16” without any sign or unsign info)The only way you can get a "signed load" is if you have an extending load which performs a sign-extension. This would usually be a result of having a load followed by a sext. What's important here is that sext produces a value of a different type than the input. If you insert a sext from i16 after the load, you will end up with a value of a wider type, say i32. Similarly, trunc will change the type to something shorter, in your case it could be from i32 back to i16. This combination is a no-op and LLVM will remove it. If you insert only the extension then you will have to change the rest of the program to accomodate the new value type.> questions: > (1) How could I pass the “sign” flag to customLowering?You could make the i16 type be not-legal. Then any load of i16 will be replaced with an extload to a wider legal type. Then you can have a selection pattern that picks sign-extending load for extload. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation