Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARM THUMB: cpy instruction mustn't be emitted by default #1760

Closed
llvmbot opened this issue May 5, 2007 · 8 comments
Closed

ARM THUMB: cpy instruction mustn't be emitted by default #1760

llvmbot opened this issue May 5, 2007 · 8 comments
Labels
backend:ARM bugzilla Issues migrated from bugzilla

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented May 5, 2007

Bugzilla Link 1388
Resolution FIXED
Resolved on May 18, 2015 07:11
Version trunk
OS All
Depends On llvm/llvm-bugzilla-archive#1401
Reporter LLVM Bugzilla Contributor
CC @john-brawn-arm

Extended Description

The cpy instruction is only defined in ARMv6.

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 8, 2007

A possible solution for this bug is to emit 'mov' instead of 'cpy'. The problem
is that the mov sets the flags and I'm afraid that it can break something in
rematerialization.

Cheng?

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 8, 2007

If all mov are changed to cpy, the backend emits wrong code:

    cmp r5, r2
    mov r0, r5
    bgt .LBB1_6     @​cond_true99

@llvmbot
Copy link
Collaborator Author

llvmbot commented May 9, 2007

The proper fix is to model CC as explicit register(s). Then you can fix the scheduler and register allocator,
i.e. any machine instruction level module that insert move, load, store ops, to insert instructions at the
right spot to avoid clobbering the CC registers. Not only is it useful for this bug, it also makes it easier to
implement a pass that optimize away cmp / test, etc.

Perhaps it's ok to just add instruction properties that tells us whether a instruction sets / reads CC. It's
hard to say.

@lattner
Copy link
Collaborator

lattner commented May 9, 2007

removing me from cc list. I am aka unassignedbugs@nondot, so I'm getting two copies :)

@lattner
Copy link
Collaborator

lattner commented May 9, 2007

FWIW, I think that it is about time we start modelling CC's correctly. This would require, at the minimum,
adding a new physreg to represent the CC, then marking each instruction that sets it as clobbering it.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Jul 8, 2010

It's better to model each flag individually e.g. N, Z, C, V, Q, the GE bits (collectively) etc. That way you can correctly model instructions that set N and Z but leave C and V unaffected. This allows you to move a MOV in between a CMP and a BCS, or between an ADDS and an ADC.

@john-brawn-arm
Copy link
Collaborator

This was fixed by r216138:

Author: Jonathan Roelofs jonathan@codesourcery.com
Date: Wed Aug 20 23:38:50 2014 +0000

Lower thumbv4t & thumbv5 lo->lo copies through a push-pop sequence

On pre-v6 hardware, 'MOV lo, lo' gives undefined results, so such copies need to
be avoided. This patch trades simplicity for implementation time at the expense
of performance... As they say: correctness first, then performance.

See http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075998.html for a few
ideas on how to make this better.

AsmParser also doesn't permit MOV lo, lo (or CPY, as it used to be known), so you can't use it in embedded asm, but MC does permit it, so using clang to assemble a .s file with --target=thumbv4t-none-eabi gives no error but should. That's less of a problem though.

@lattner
Copy link
Collaborator

lattner commented Nov 26, 2021

mentioned in issue llvm/llvm-bugzilla-archive#1401

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend:ARM bugzilla Issues migrated from bugzilla
Projects
None yet
Development

No branches or pull requests

3 participants