Displaying 6 results from an estimated 6 matches for "iptr256".
2013 Jun 23
0
[LLVMdev] Register Class assignment for integer and pointer types
Hi,
In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers. This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types. We've added a flag that can be set on a per-backend basis to turn this off.
Our problem is perhaps a bit different form you...
2013 Jun 24
1
[LLVMdev] Register Class assignment for integer and pointer types
2013/6/23 David Chisnall <David.Chisnall at cl.cam.ac.uk>
> Hi,
>
> In our version of LLVM, we've added different-sized iPTR* types, so we
> have an iPTR256 for our fat pointers. This causes some problems with
> constraints, because the way that TableGen resolves constraints is not
> expected to handle multiple pointer types. We've added a flag that can be
> set on a per-backend basis to turn this off.
> Our problem is perhaps a bit...
2013 Jun 23
3
[LLVMdev] Register Class assignment for integer and pointer types
David, thanks for your immediate response.
Since iPTR is a reserved type for tablegen internal use, can you make a
further explanation?
On the other hand, it can be simply treated as a register class assignment
problem during register allocation.
Assume both pointer and integet have a 32 bit width. backend handles it
just as to i32. When it performs register allocation, it can retrieve from
2013 Jun 24
2
[LLVMdev] Register Class assignment for integer and pointer types
On Sun, Jun 23, 2013 at 04:57:44PM +0100, David Chisnall wrote:
> Hi,
>
> In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers. This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types. We've added a flag that can be set on a per-backend basis to turn this off.
>
I've been following this thread, and I...
2013 Aug 08
0
[LLVMdev] Address space extension
Sent from my iPhone
> On Aug 8, 2013, at 5:39 AM, Michele Scandale <michele.scandale at gmail.com> wrote:
>
>> On 08/08/2013 02:16 PM, Justin Holewinski wrote:
>> Why should SelectionDAGBuilder generate an explicit bitcast for a no-op
>> bitcast?
>
> The bitcast operation isn't just the reinterpretation (change in the semantic) of the bits without any
2013 Aug 08
5
[LLVMdev] Address space extension
On 08/08/2013 02:16 PM, Justin Holewinski wrote:
> Why should SelectionDAGBuilder generate an explicit bitcast for a no-op
> bitcast?
The bitcast operation isn't just the reinterpretation (change in the
semantic) of the bits without any change in the value of the bits
itself? If the size and value do not change should be fine.
> By definition, no bits are changed; so if the EVTs