Closed Bug 587236 Opened 14 years ago Closed 14 years ago

TM: Inevitable android regexp test breakage from PCRE

Categories

(Core :: JavaScript Engine, defect)

ARM
Android
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: cdleary, Assigned: cdleary)

Details

Android will experience jsreftest breakage until the ARMv7Assembler is working on that platform. Ultimately, these breakages need to be fixed via PCRE, but just getting ARMv7Assembler building/running/tested would work in the meantime.
References, but does not block, bug 587183.
No longer blocks: 587183
tracking-fennec: --- → ?
OS: Linux → Android
Hardware: x86_64 → ARM
Do you mean "ARMv7Assembler"? That is WebKit's name for the Thumb-2 back-end. I've only looked at the "ARMAssembler" back-end, which generates ARM code (including ARMv7 ARM code). Yes, the naming scheme is confusing, but I'd rather not change it as it will confuse merges from WebKit in the future.

I've not integrated the Thumb ("ARMv7") back-end yet, but the ARM back-end works. Well, actually the YARR stuff is broken, but it builds and passes most trace-tests. I have half a fix for YARR.
(In reply to comment #2)

Cool, I'll refer to it as Thumb-2 assembler from now on. I guess our android build wants to use Thumb-2 by default.

Would you say that, for any device that uses Thumb-2, the ARMAssembler will be sufficient? Maybe we can just muck around in the build flow to get things working there if we really care.
The non-v7 assembler should be fine, but we'd like to use the v7 (t2) one if at all possible, if we're doing a thumb2 build.  For android in particular, the devices we care about are all armv7, so the thumb2 build provides a decent code compactness boost.
Thumb-2 is slightly more compact than ARM code, but I think the ARM back-end actually performs slightly better (at least in the context of WebKit) so I hadn't prioritized a port. It's quite feasible to do, but will some work to bring it in-line with the ARM back-end. I plan to do it, but my priority for the next couple of weeks is getting the ARM port fully functional (with PICs and the like).

You should have no problems building the engine for Thumb-2 but using the ARM back-end as all the branches should interwork. However, the build system isn't really set up to do this at the moment so for now you'll have to build it all as ARM code.

In the past, we found that whilst Thumb-2 is good for static code, it's not quite as convenient for JIT-compiled code. For one thing, the code compactness doesn't matter as much, but it's also more complicated to encode than ARM. Still, most of the code exists, so it's worth experimenting with.
Oh, by the way, anything that implements Thumb-2 will also implement ARM, so don't worry about the compiler options.

There are some embedded processors — the Cortex-M range — that only implement Thumb-2 (or a variant of it), but they aren't anywhere near our target market.
Ah, I didn't realize that the t2 backend wouldn't necessarily build us any wins.  I (or someone else) can do the build system work to let things build as t2 + arm backend.  However, presumably the ARM backend is also supporting previous-to-armv7 CPUs; if there are any specific places where ARMv7 instructions would be helpful, we should probably add that via compile/runtime switch if they don't exist already.  (I haven't looked at the code in question yet at all, so apologies if I'm talking about things that it already does!)
what's the implication of this and why should it block fennec?
We should be ok after bug 587597, no? We use ARMAssembler now.
Clearing the blocking-fennec flag - I set it because I wasn't sure if this was necessary for getting YARR enabled on Android.
tracking-fennec: ? → ---
If we're using ARMAssembler on Android I can close this as invalid.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.