llvm dev - Oct 2012 - [LLVMdev] [llvm-commits] [cfe-commits] [PATCH] [llvm+clang] memset for non-8-bit bytes

> Please start a thread on llvmdev about this functionality, and outline what
other intrinsics will have to change to add non-8-bit byte support.
Well, memset is the only we have seen so far (our back-end is ~50% finished for
an initial release). We have our own front-end as well (we are currently not
using the clang front-end), and currently don't use many llvm intrinsics
(only llvm.stacksave/llvm.stackrestore). The memset intrinsic is generated by
opt.
> This isn't the sort of feature that we just add without understanding
the full impact.
The large impact we have seen is in other parts, regarding the assumtion that a
byte is 8 bits. You can see a diffstat of our current patch below. However, this
patch for non 8-bit bytes is a more clean approach to core changes:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120702/146050.html

It is on my todo-list to merge that patch with our changes. Do you want that
kind of changes to be pushed first?

Regards,
Patrik Hägglund

 include/llvm/CodeGen/SelectionDAG.h               |  2 +-
 include/llvm/CodeGen/ValueTypes.h                 | 43
++++++++++++++++++++++++++++++++-----------
 include/llvm/DataLayout.h                         | 22 ++++++++++++++++------
 include/llvm/IRBuilder.h                          | 16 ++++++++++++++++
 lib/Analysis/ConstantFolding.cpp                  | 74
++++++++++++++++++++++++++++++++++++++++----------------------------------
 lib/Analysis/ValueTracking.cpp                    | 22 +++++++++++++---------
 lib/CodeGen/AsmPrinter/AsmPrinter.cpp             | 50
++++++++++++++++++++++++++++++++++++++------------
 lib/CodeGen/AsmPrinter/AsmPrinterDwarf.cpp        |  6 ++++--
 lib/CodeGen/AsmPrinter/DIE.cpp                    | 20 ++++++++++++--------
 lib/CodeGen/AsmPrinter/DwarfDebug.cpp             |  7 ++++---
 lib/CodeGen/MachineFunction.cpp                   |  2 +-
 lib/CodeGen/SelectionDAG/DAGCombiner.cpp          | 58
+++++++++++++++++++++++++++++++++-------------------------
 lib/CodeGen/SelectionDAG/LegalizeDAG.cpp          | 63
++++++++++++++++++++++++++++++++++-----------------------------
 lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp   |  4 ++--
 lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp | 18 +++++++++---------
 lib/CodeGen/SelectionDAG/LegalizeTypes.cpp        |  2 +-
 lib/CodeGen/SelectionDAG/LegalizeTypesGeneric.cpp | 12 ++++++------
 lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp  | 14 +++++++-------
 lib/CodeGen/SelectionDAG/SelectionDAG.cpp         | 89
+++++++++++++++++++++++++++++++++++++++++++----------------------------------------------
 lib/CodeGen/SelectionDAG/TargetLowering.cpp       |  6 +++---
 lib/Transforms/InstCombine/InstCombineCalls.cpp   |  6 ++++--
 lib/Transforms/Scalar/GVN.cpp                     | 48
++++++++++++++++++++++++++++++------------------
 lib/Transforms/Scalar/SROA.cpp                    | 96
+++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------
 lib/Transforms/Scalar/ScalarReplAggregates.cpp    | 18 +++++++++++-------
 lib/VMCore/DataLayout.cpp                         | 65
++++++++++++++++++++++++++++++++++++++++++++++-------------------
 lib/VMCore/IRBuilder.cpp                          | 23 ++++++++++++++++++-----
 lib/VMCore/ValueTypes.cpp                         |  2 ++
 lib/VMCore/Verifier.cpp                           |  2 ++
 test/CodeGen/PowerPC/structsinmem.ll              |  8 ++++----
 test/CodeGen/PowerPC/structsinregs.ll             | 14 +++++++-------
 test/CodeGen/X86/memcpy-2.ll                      |  4 ++--
 test/CodeGen/X86/pr11985.ll                       |  6 +++---
 test/CodeGen/X86/unaligned-load.ll                | 10 +++++++++-
 33 files changed, 506 insertions(+), 326 deletions(-)


-----Original Message-----
From: Chris Lattner [mailto:clattner at apple.com] 
Sent: den 19 oktober 2012 00:03
To: Patrik Hägglund H
Cc: llvm-commits at cs.uiuc.edu; cfe-commits at cs.uiuc.edu
Subject: Re: [cfe-commits] [PATCH] [llvm+clang] memset for non-8-bit bytes


On Oct 18, 2012, at 6:11 AM, Patrik Hägglund H <patrik.h.hagglund at
ericsson.com> wrote:
> We have a back-end with 16-bit bytes, and have changed the memset
> intrinsics to be able to work on arbitrary word sizes, just as memcpy.
Hi Patrik,

This is interesting.  Please start a thread on llvmdev about this functionality,
and outline what other intrinsics will have to change to add non-8-bit byte
support.  This isn't the sort of feature that we just add without
understanding the full impact.

Also, to actually roll this out, you'll need to add
lib/VMCore/AutoUpgrade.cpp support for this change, because we need to be able
to read old .bc and .ll files that use the previous form of the intrinsic.

-Chris
> 
> This patch updates the type of the second parameter of memset in
> Intrinsics.td, from llvm_i8_ty, to llvm_anyint_ty:
> 
> def int_memset  : Intrinsic<[],
> -                            [llvm_anyptr_ty, llvm_i8_ty, llvm_anyint_ty,
> +                            [llvm_anyptr_ty, llvm_anyint_ty,
llvm_anyint_ty,
>                              llvm_i32_ty, llvm_i1_ty],
> 
> IRBuilder.cpp and LangRef.html is updated accordingly.
> 
> To use the intrinsic, the declaration,
> 
>  declare void @llvm.memset.p0i8.i32(i8* <dest>, i8 <val>,
>                                     i32 <len>, i32 <align>, i1
<isvolatile>)
> 
> now becomes
> 
>  declare void @llvm.memset.p0i8.i8.i32(i8* <dest>, i8 <val>,
>                                        i32 <len>, i32 <align>,
i1 <isvolatile>)
> 
> The bulk of this patch consists of such changes (mainly in tests).
> 
> Some tests in clang has to be updated, as shown by the second patch file.
> 
> /Patrik Hägglund  
>
<0002-clang-Change-memset-in-Intrinsics.td-to-take-anyint.patch><0001-llvm-Change-memset-in-Intrinsics.td-to-take-anyint.patch>_______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

On Oct 19, 2012, at 2:24 AM, Patrik Hägglund H <patrik.h.hagglund at
ericsson.com> wrote:
>> non-8-bit byte 
I'm a bit confused by this concept. I'm aware of the archaic meaning of
the word byte, but it has meant 8 bits for the last 30 years. There's even
an ISO/IEC standard.

I know of architectures like Texas' C55x DSPs that address 16 bits at a
time, but even their data sheets state:

• 256K Bytes Zero-Wait State On-Chip RAM, Composed of:
  • –  64K Bytes of Dual-Access RAM (DARAM), 8 Blocks of 4K x 16-Bit
  • –  192K Bytes of Single-Access RAM (SARAM), 24 Blocks of 4K x 16-Bit

Perhaps you could begin by defining more accurately what you're talking
about?

/jakob

On Fri, Oct 19, 2012 at 9:27 AM, Jakob Stoklund Olesen <stoklund at
2pi.dk> wrote:
>
> On Oct 19, 2012, at 2:24 AM, Patrik Hägglund H <patrik.h.hagglund at
ericsson.com> wrote:
>
>>> non-8-bit byte
>
> I'm a bit confused by this concept. I'm aware of the archaic
meaning of the word byte, but it has meant 8 bits for the last 30 years.
There's even an ISO/IEC standard.
>
> I know of architectures like Texas' C55x DSPs that address 16 bits at a
time, but even their data sheets state:
>
> • 256K Bytes Zero-Wait State On-Chip RAM, Composed of:
>   • –  64K Bytes of Dual-Access RAM (DARAM), 8 Blocks of 4K x 16-Bit
>   • –  192K Bytes of Single-Access RAM (SARAM), 24 Blocks of 4K x 16-Bit
>
> Perhaps you could begin by defining more accurately what you're talking
about?
I'm assuming he means an architecture where CHAR_BIT > 8.

-Eli

> I'm a bit confused by this concept. 
For the term byte, I use the "archaic" definition in the C (and C++)
standard (section 3.6):

  addressable unit of data storage large enough to hold any member of the basic
character
  set of the execution environment

/Patrik Hägglund 

-----Original Message-----
From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] 
Sent: den 19 oktober 2012 18:28
To: Patrik Hägglund H
Cc: Chris Lattner; llvmdev at cs.uiuc.edu
Subject: Re: [llvm-commits] [cfe-commits] [PATCH] [llvm+clang] memset for
non-8-bit bytes


On Oct 19, 2012, at 2:24 AM, Patrik Hägglund H <patrik.h.hagglund at
ericsson.com> wrote:
>> non-8-bit byte 
I'm a bit confused by this concept. I'm aware of the archaic meaning of
the word byte, but it has meant 8 bits for the last 30 years. There's even
an ISO/IEC standard.

I know of architectures like Texas' C55x DSPs that address 16 bits at a
time, but even their data sheets state:

. 256K Bytes Zero-Wait State On-Chip RAM, Composed of:
  . -  64K Bytes of Dual-Access RAM (DARAM), 8 Blocks of 4K x 16-Bit
  . -  192K Bytes of Single-Access RAM (SARAM), 24 Blocks of 4K x 16-Bit

Perhaps you could begin by defining more accurately what you're talking
about?

/jakob