Jeff Law <jeffreya...@gmail.com> writes: > On 8/29/24 10:13 AM, John David Anglin wrote: >> Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11. >> Committed to trunk. >> >> Dave >> --- >> >> hppa: Fix handling of unscaled index addresses on HP-UX >> >> The PA-RISC architecture uses the top two bits of memory pointers >> to select space registers. The space register ID is ored with the >> pointer offset to compute the global virtual address for an access. >> >> The new late combine passes broke gcc on HP-UX. One of these passes >> runs after reload. The existing code assumed no unscaled index >> instructions would be created after reload as the REG_POINTER flag >> is not reliable after reload. The new pass sometimes interchanged >> the base and index registers, causing these instructions to fault >> when the wrong space register was selected. > Implicit space register selection based on the index rather than the > effective address. A thorn in my side for years working on the PA. > >> >> The flag is not propagated when a constant is added to a pointer. > IIRC one of the problems in this space was Ada would tend to create > pointers outside an object's bounds, then use an offset to bring the > effective address back into the object. And tail merging would tend to > do things like see a path with a + b and another with b + a as addresses > and assume it could commonize the paths. All kinds of dragons in here. > I tried damn hard to support unscaled indexing, but it was always quite > painful. > > >> Thus, I came to the conclusion that the best approach was to >> disable use of unscaled index addresses on HP-UX. I don't think >> this impacts performance significantly. Code size might get >> slightly larger but we get some or more back from having the late >> combine passes. > I can certainly live with this as I don't have to use HPUX anymore ;-) > Presumably Linux has a flat address model with the space registers > holding the same value. That's what we did with our BSD and Mach ports > to the PA and was what PRO was recommending to members back in the day... > > It may be worth noting that if anyone still has mn10300 silicon it had > similar properties. Though it may have been limited to the first > generation, I vaguely recall a Matsushita engineer I worked with > indicating they considered it a silicon bug.
Can't remember if I've mentioned this before, but FWIW: as part of the Morello port, it was vital for correctness that we could distinguish bases from indices. We ended up adding a new mode class for pointers (used only on targets that need them). We also added pointer_plus and pointer_diff rtx codes, along the lines of the tree/gimple operations (again only used on targets that need them). We added abstractions that were supposed to make it easy for target-independent code to do the right thing. For real Morello, the pointer capabilities were 128 bits, and so they were easy to tell apart from indices. However, for testing purposes, we also had a "fake capability" mode that used the Morello-style representation for normal AArch64 code, with 64-bit pointers. It seemed to work pretty well. Something like the fake capability approach might be useful for targets like PA. Morello was an experimental architecture, so there are no current plans to submit support for trunk. It's available in vendors/ARM/heads/morello for anyone's who curious though. (As always, there was quite a bit of learning by doing, so we'd need to go back and clean the branch up if we did ever submit parts to trunk.) Richard
