Inconsistency in the LLVM docs

http://llvm.org/docs/LangRef.html#i_inttoptr

The ‘inttoptr’ instruction takes an integer value to cast, and a type to cast it to, which must be a pointer type.

The final example is:

%Z = inttoptr <4 x i32> %G to <4 x i8*>; yields truncation of vector G to four pointers

The result is not a pointer type, but a vector of pointer types. This violates the restriction of the arguments.

Is this an overview, or should this instruction type be illegal?

Micah

Hi Micah,

We need to fix the documentation here. We want to be able to convert vectors of integers to vectors of pointers and back.

There are a few tests such as (/InstCombine/vector_gep1.ll) that check for these conversions.

Nadav

Yes I know, I’m having problems with these tests because they violate the documentation. J

Micah

Villmow, Micah wrote:

http://llvm.org/docs/LangRef.html#i_inttoptr

The 'inttoptr' instruction takes aninteger
<http://llvm.org/docs/LangRef.html#t_integer>value to cast, and a type
to cast it to, which must be apointer
<http://llvm.org/docs/LangRef.html#t_pointer>type.

The final example is:

%Z = inttoptr <4 x i32> %G to <4 x i8*>/; yields truncation of vector G
to four pointers/

The result is not a pointer type, but a vector of pointer types. This
violates the restriction of the arguments.

Is this an overview, or should this instruction type be illegal?

I think this is intended to be legal. Have you checked the verifier (I haven't)? There might be a few places left in LangRef where 'integer', 'pointer' or 'float' should read template<typename T>'T or vector of Ts', if you're interested in auditing it.

Nick

I have a project - http://parallel.cc - the goal of which is to replace a bunch of hardware design/description languages with an extended C++ (ParC) that supports the same paradigms. The current plan is (roughly) to do open-source translators to ParC from SystemC, Verilog, VHDL, SysytemVerilog and Verilog-AMS, and process ParC with Clang++ attempting to hang onto the threading and messaging structures.

ParC should be usable for programming many-core and FPGA platforms.

What I would like to know is how much work would be involved in adding the necessary support in LLVM/Clang++, and does anyone want to help (paid or unpaid). The basic constructs I need are:

a) an event object
b) a "pipe" object
c) a process object

The event object is something to which you can attach process call-backs.
The pipe is just an object which you can write a particular class to, e.g. "pipe<int>" to relay ints from one place to another (and may also be an event object).
The process is essentially just a class with a bunch call-back methods. Since it's one block of code it could be viewed as a routine with multiple entry/exit points, rather than multiple methods.

Examples of ParC source code can be found here -

  http://v2k.cvs.sourceforge.net/viewvc/v2k/tests/ParC/examples/async_life.pc
  http://v2k.cvs.sourceforge.net/viewvc/v2k/tests/ParC/examples/sync_life.pc

The other piece in doing HDLs is "signals", but I'm expecting that just to be a runtime library thing. However, it is worth noting the "signal resolution" is akin to handling mutexes/locking.

Signals and pipes are mechanisms that avoid having to have cache-coherent shared memory, so this is a scalable computing paradigm (like CSP).

All feedback/questions appreciated.

Kev.