[PATCH] D12838: [GlobalsAA] Teach GlobalsAA about memory intrinsics

[James Molloy via llvm-commits]

Hi Arnaud,

I'm not sure the definition of volatile is sufficiently wide to allow the
changing of a reference into a modification or vice versa? volatility at
this level is just to do with expected memory access ordering AIUI. I
understand being conservative in this case but I'm not 100% convinced we
need to be *that* conservative.

James

On Mon, 14 Sep 2015 at 16:02 Arnaud de Grandmaison via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> aadg added a subscriber: aadg.
> aadg added a comment.
>
> Hi James,
>
> See comment below.
>
>
> ================
> Comment at: lib/Analysis/GlobalsModRef.cpp:776-782
> @@ +775,9 @@
> +  default:
> +    return MRI_ModRef;
> +  case Intrinsic::memset:
> +    return (Operands[0] ? MRI_Mod : MRI_NoModRef);
> +  case Intrinsic::memcpy:
> +  case Intrinsic::memmove:
> +    return static_cast<ModRefInfo>((Operands[0] ? MRI_Mod : MRI_NoModRef)
> |
> +                                   (Operands[1] ? MRI_Ref :
> MRI_NoModRef));
> +  }
> ----------------
> Shouldn't we also handle the isVolatile argument ? As anything could
> happen when this is a volatile operation, I think we should always return
> MRI_ModRef when it is set.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D12838
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150914/1ec6d22a/attachment.html>