llvm dev - Jan 2015 - [LLVMdev] Bug in InsertElement constant propagation?

I don't see a way to create a ConstantDataVector from Constant or form
APFloat though. Did I oversee that?
Is the solution to had a new get function in ConstantDataVector to allow that?
Any hint on what would be the right fix otherwise?

Thomas

-----Original Message-----
From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] 
Sent: Wednesday, January 14, 2015 10:30 AM
To: Raoux, Thomas F; LLVM Developers Mailing List
Subject: Re: [LLVMdev] Bug in InsertElement constant propagation?



On 1/14/15 11:12 AM, Raoux, Thomas F wrote:
> Ha here is what I was missing. Thanks Jon. It still seems to me that the
transformation of LLVM IR is invalid is that right?
I don't know if IR is required to preserve NaN bit patterns, but ISTM that
it would be better if it did.
> I assume we shouldn't be converting APFloat to float in order to avoid
such problems?
Yes, I think that's the correct fix.

Jon

--
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

I'm not sure what the right fix is. I don't see a way to get the float 
out of APFloat without a copy happening. The usual trick to copy a float 
somewhere else but preserve the NaN bits is to use memcpy.

Jon

On 1/15/15 2:29 AM, Raoux, Thomas F wrote:
> I don't see a way to create a ConstantDataVector from Constant or form
APFloat though. Did I oversee that?
> Is the solution to had a new get function in ConstantDataVector to allow
that? Any hint on what would be the right fix otherwise?
>
> Thomas
>
> -----Original Message-----
> From: Jonathan Roelofs [mailto:jonathan at codesourcery.com]
> Sent: Wednesday, January 14, 2015 10:30 AM
> To: Raoux, Thomas F; LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Bug in InsertElement constant propagation?
>
>
>
> On 1/14/15 11:12 AM, Raoux, Thomas F wrote:
>> Ha here is what I was missing. Thanks Jon. It still seems to me that
the transformation of LLVM IR is invalid is that right?
> I don't know if IR is required to preserve NaN bit patterns, but ISTM
that it would be better if it did.
>> I assume we shouldn't be converting APFloat to float in order to
avoid such problems?
> Yes, I think that's the correct fix.
>
> Jon
>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
>
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

Does anybody else have an opinion on this issue? I'm planning to submit a
patch which would add a new get method for ConstantDataVector taking an
ArrayRef<Constant*> and use that in the few places in constant propagation
where convertToFloat is used.

Let me know if you think there is a more obvious way to do it.

Right now the only way to create a ConstantDataVector are those method:

  /// get() constructors - Return a constant with vector type with an element
  /// count and element type matching the ArrayRef passed in.  Note that this
  /// can return a ConstantAggregateZero object.
  static Constant *get(LLVMContext &Context, ArrayRef<uint8_t> Elts);
  static Constant *get(LLVMContext &Context, ArrayRef<uint16_t> Elts);
  static Constant *get(LLVMContext &Context, ArrayRef<uint32_t> Elts);
  static Constant *get(LLVMContext &Context, ArrayRef<uint64_t> Elts);
  static Constant *get(LLVMContext &Context, ArrayRef<float> Elts);
  static Constant *get(LLVMContext &Context, ArrayRef<double> Elts);

  /// getSplat - Return a ConstantVector with the specified constant in each
  /// element.  The specified constant has to be a of a compatible type (i8/i16/
  /// i32/i64/float/double) and must be a ConstantFP or ConstantInt.
  static Constant *getSplat(unsigned NumElts, Constant *Elt);

Cheers,
Thomas


-----Original Message-----
From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] 
Sent: Thursday, January 15, 2015 6:36 AM
To: Raoux, Thomas F; LLVM Developers Mailing List
Subject: Re: [LLVMdev] Bug in InsertElement constant propagation?

I'm not sure what the right fix is. I don't see a way to get the float
out of APFloat without a copy happening. The usual trick to copy a float
somewhere else but preserve the NaN bits is to use memcpy.

Jon

On 1/15/15 2:29 AM, Raoux, Thomas F wrote:
> I don't see a way to create a ConstantDataVector from Constant or form
APFloat though. Did I oversee that?
> Is the solution to had a new get function in ConstantDataVector to allow
that? Any hint on what would be the right fix otherwise?
>
> Thomas
>
> -----Original Message-----
> From: Jonathan Roelofs [mailto:jonathan at codesourcery.com]
> Sent: Wednesday, January 14, 2015 10:30 AM
> To: Raoux, Thomas F; LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Bug in InsertElement constant propagation?
>
>
>
> On 1/14/15 11:12 AM, Raoux, Thomas F wrote:
>> Ha here is what I was missing. Thanks Jon. It still seems to me that
the transformation of LLVM IR is invalid is that right?
> I don't know if IR is required to preserve NaN bit patterns, but ISTM
that it would be better if it did.
>> I assume we shouldn't be converting APFloat to float in order to
avoid such problems?
> Yes, I think that's the correct fix.
>
> Jon
>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
>
--
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded