search for: ptradd

...zation), which is way less than ideal. It also uses 32-bit frameindexes (it treats the stack as 32-bit despite global pointers being 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...

...e have a set of out-of-tree patches that extend the data layout to understand that there’s a difference between the size and the range of a pointer (e.g. a 128-bit pointer can store 64-bit addresses + metadata) and fixes for all of the optimisers that we’ve found, and SelectionDAG. We add explicit PTRADD, INTTOPTR and PTRTOINT nodes in SelectionDAG for architectures where pointer+integer is distinct from integer arithmetic and where inttoptr / ptrtoint are not bitcasts. > I have full arithmetic set for 32-bit integers, but the Ptr is wider. Extending index to the Ptr width requires full arithme...

> 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

Hi all, I'm working on an out-of-tree target and encountered the following problem: InstCombiner "normalizes" GEPs and extends Index operand to the Pointer width. It works fine if you can convert pointer to integer for address calculation and I assume that all registered targets do this. The target I'm working on has very restricted ISA for the

...e have a set of out-of-tree patches that extend the data layout to understand that there’s a difference between the size and the range of a pointer (e.g. a 128-bit pointer can store 64-bit addresses + metadata) and fixes for all of the optimisers that we’ve found, and SelectionDAG. We add explicit PTRADD, INTTOPTR and PTRTOINT nodes in SelectionDAG for architectures where pointer+integer is distinct from integer arithmetic and where inttoptr / ptrtoint are not bitcasts. > I have full arithmetic set for 32-bit integers, but the Ptr is wider. Extending index to the Ptr width requires full arithme...

...space they are in). > >> 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...

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

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