search for: ifatptr

...g 64-bit), so I don’t think that provides a usable template for a solution here, unfortunately. If it would help, one of the changes that we’ve made is to add separate PTRADD, INTTOPTR and PTRTOINT nodes to SelectionDAG, which makes it possible to keep pointer types distinct. We currently have an iFATPTR type, which is not ideal - we’d like to replace this with a set of PTR32 to PTR256 types. I’d be happy to prioritise extracting these patches for upstreaming if that would be useful to others. David

> On Nov 19, 2015, at 9:50 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > > On 19 Nov 2015, at 17:49, Quentin Colombet <qcolombet at apple.com> wrote: >> >> I must miss something, but I don’t get what is the problem of lower the pointer to actual integer. > > Pointers, in our architecture, are not integers. Thanks for the clarifications. So

...ve done this in our tree. Finally, don't forget that you'd also need to add an address space cast instruction to the SelectionDAG. I added PTRTOINT and INTTOPTR ones in our tree because I didn't want to make the invasive change to the IR that really needed. We also needed to add an iFATPTR to the ValueTypes, but for the more general solution (the reason I haven't pushed ours upstream is that it's full of ugly hacks and FIXMEs) you'd need the possibility of multiple iPTR-like types with different sizes. Possibly just enumerating the plausible ones would work (ours are 256...

.... > >> I am trying to understand the constraint to see how that would fit in the framework. That being said, anything that you could do in SDag should be possible as well in the new framework. > > We currently add several new nodes to SDag: INTTOPTR, PTRTOINT, and PTRADD, and a new iFATPTR MVT. The last is somewhat problematic, as we really want to have iFATPTR128 and iFATPTR256 (and, potentially, iFATPTR64 for an IoT/embedded variant). > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev...

Hi, I recently started helping with the LLVM AVR backend [1]. The AVR is an 8 bit core with pointer type i16. That makes pointers illegal in the SelectionDAG. As far as I understand it, it is the backends job to legalize these nodes by using the ReplaceNodeResults/LowerOperation callbacks. Is that about right? I have the feeling that the symbolic nodes carrying pointers, like FrameIndex are

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

Hello all, I would like to propose a large change to LLVM that I would be happy to implement. The instruction selection legalizer knows of three different ways to legalize an action (ignoring an already legal action). - Expansion - Promotion - Custom Expanding a node will lead to one of two things - the operation will be split into several equivalent smaller operations (i.e. 64-bit

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