> >> So it handles all const expression evaluation in the front-end? >> >> > Yes, clang has it's own constant expression evaluator which understands > the rules of C++. > > Let's take an example. > The expression (long)&x/(long)&y divides two globals by each other. This > expression is lowered to the following LLVM IR Constant: > i64 sdiv (i64 ptrtoint (i32* @x to i64), i64 ptrtoint (i32* @y to i64)) > > This Constant is a ConstantExpr but certainly not indicative of something > that would be 'constexpr' in C++. >My goal is to be able to use the result in constexpr contexts (like declaring an array, whose size expression involves offsetof()). Please correct me if this is wrong, but I think this means that the expression must be evaluated before any IR is emitted. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150102/2549b787/attachment.html>
On Fri, Jan 02, 2015 at 05:26:42PM -0800, Vadim Chugunov wrote:> My goal is to be able to use the result in constexpr contexts (like > declaring an array, whose size expression involves offsetof()). Please > correct me if this is wrong, but I think this means that the expression > must be evaluated before any IR is emitted.Do you start from offsetof() or the expanded form? For various reasons, it is normally defined to use __builtin_offsetof, since the problems you have run into also stop the "legacy" C version from being appropoiate for C++ as it doesn't create an ICE. Joerg
> Do you start from offsetof() or the expanded form? For various reasons, > it is normally defined to use __builtin_offsetof, since the problems you > have run into also stop the "legacy" C version from being appropoiate > for C++ as it doesn't create an ICE. >I start with a macro, but I was considering expanding it to pointer arithmetic, to avoid creating special operators such as __builtin_offsetof. Would that be considered a bad idea? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150103/b7c5351b/attachment.html>