[PATCH] D14983: Introduce new @llvm.getdynamicareaoffset.i{32, 64} intrinsic.

[Maxim Ostapenko via llvm-commits]

m.ostepenko added inline comments.

================
Comment at: include/llvm/CodeGen/ISDOpcodes.h:761
@@ +760,3 @@
+    /// nonzero constant. The only operand here is the chain.
+    GET_DYNAMIC_AREA_OFFSET,
+
----------------
m.ostepenko wrote:
> hfinkel wrote:
> > What's the return type? Always the pointer type?
> > 
> > What happens if someone declares this with type i32 on a 64-bit system? We should not just randomly assert somewhere in this case; either handle it by doing an extend-or-truncate somewhere, or issue an error somewhere if the type does not match the pointer size type, and document the requirement in the LangRef.
> > 
> Hm, I use //llvm_anyint_ty// in IR/Intrinsics.td, so I suspect this should be i32 for 32-bit targets and i64 for 64-bit ones. So, it seems that for most targets that would be pointer type, right?
> >What happens if someone declares this with type i32 on a 64-bit system? We should not just randomly assert somewhere in this case; either handle it by doing an extend-or-truncate somewhere, or issue an error somewhere if the type does not match the pointer size type, and document the requirement in the LangRef.
> If I understand you correctly, you mean what happens if someone add new custom lowering routine for some target, right? If someone declares this intrinsic with a wrong type, he would get //Expand// action in //Action = TLI.getOperationAction// during node legalization in //SelectionDAGLegalize::LegalizeOp//. Issuing an error in such a case would be nice, thought.
>> What happens if someone declares this with type i32 on a 64-bit system? We should not just randomly assert somewhere in this case; either handle it by doing an extend-or-truncate somewhere, or issue an error somewhere if the type does not match the pointer size type, and document the requirement in the LangRef.
> If I understand you correctly, you mean what happens if someone add new custom lowering routine for some target, right? If someone declares this intrinsic with a wrong type, he would get Expand action in Action = TLI.getOperationAction during node legalization in SelectionDAGLegalize::LegalizeOp. Issuing an error in such a case would be nice, thought.
Ah, I see, perhaps you meant something like this (here we use @llvm.getdynamicareaoffset.i32() on PPC64):
```
; RUN: llc -mtriple=powerpc64-unknown-linux-gnu -mcpu=pwr7 < %s | FileCheck %s
target datalayout = "E-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f128:128:128-v128:128:128-n32:64"
target triple = "powerpc64-unknown-linux-gnu"

declare i32 @llvm.getdynamicareaoffset.i32()

declare i64 @bar(i32)

attributes #0 = { nounwind }

; Function Attrs: nounwind sanitize_address uwtable
define signext i64 @foo(i32 signext %N, i32 signext %M) #0 {
  %1 = alloca i64, align 32
  %getdynamicareaoffset1 = call i32 @llvm.getdynamicareaoffset.i32()
  %2 = call i64 @bar(i32 %getdynamicareaoffset1)
  ret i64 %2

; CHECK-DAG: li [[REG1:[0-9]+]], 112
; CHECK: blr

}
```
Sorry for being dumb here. I'll insert an assertion to corresponding handle into //visitIntrinsicCall// function.


Repository:
  rL LLVM

http://reviews.llvm.org/D14983