레지스터 이름을 바꾸는 것과 값을 복사하는 것은 다릅니다
비순차 실행 코어는 아키텍처의 레지스터 이름을 내부 물리 레지스터에 대응시킬 수 있습니다. 일부 register-to-register move는 실행 유닛에서 데이터를 복사하는 대신 목적지의 대응 관계를 바꾸는 방식으로 이해할 수 있습니다. 아래는 개념도이며 V2의 내부 회로를 관찰한 결과가 아닙니다.
이전: x2 → 물리 값 P7
x1 → 물리 값 P3
mov x1, x2 이후의 개념:
x2 → P7
x1 → P7
값의 생산자가 아직 미완료이면
두 이름 모두 그 결과를 기다림Arm 명령어 문서에서 register MOV는 ORR shifted-register의 별칭입니다. 예를 들어 orr x1,xzr,x2의 값은 0 OR x2입니다. 명령 표기만 보고 모든 ORR 또는 모든 MOV가 제거된다고 판단할 수 없습니다.
Neoverse V2의 특정 최적화이지 Arm 전체의 보장이 아닙니다
Neoverse V2 Software Optimization Guide, Issue 3.0, §4.12는 일부 MOV가 scheduling·execution 자원을 사용하지 않는 zero-latency 하위 집합임을 설명합니다. MOV Xd,Xn과 MOV Wd,Wn은 여기에 포함되지만 조건에 따라 zero latency가 아닐 수 있다는 예외가 명시되어 있습니다. 그 조건을 임의로 만들어 항상 보장되는 것으로 쓰지 않습니다.
0을 넣는 일부 MOV와 일반 즉시값 이동도 다릅니다. 같은 가이드의 §3.7은 일반 MOVN/MOVK/MOVZ를 실행 지연 1사이클로, §3.4는 일반 정수 ORR를 1사이클로 표기합니다. 특별 취급되는 하위 집합을 “move는 무료”라는 규칙으로 확장할 수 없습니다. 이 글의 범위는 해당 V2 문서이며 다른 코어·리비전은 별도 확인 대상입니다.
진짜 데이터 의존성은 없어지지 않습니다
add x9, x0, x1
mov x10, x9
sub x11, x10, x2중간 move의 추가 실행이 제거되어도 sub는 add의 결과가 준비되어야 계산할 수 있습니다. x10이라는 이름을 빨리 대응시키는 것과 그 값이 이미 준비된 것은 다릅니다. fetch·decode 등 프런트엔드가 처리할 명령도 남습니다.
zero latency는 프로그램 전체 실행 시간이 0이라는 뜻도, 모든 상황에서 처리량이 무제한이라는 뜻도 아닙니다. 의존 사슬의 지연과 여러 독립 명령의 처리량을 다른 실험으로 확인해야 합니다. 여기에는 실행 포트 사용률이나 실측 사이클 수를 제시하지 않습니다.
llvm-mca 출력은 스케줄 모델의 추정입니다
llvm-mca는 대상 모델로 처리량·자원 사용을 추정하며 완전한 CPU 시뮬레이터가 아닙니다. 실행 자원 칸이 비어 있는 것을 실칩 계측값으로 읽지 않습니다. Neoverse V2 zero-latency move 모델 변경 D159443처럼 모델도 수정되므로 도구 버전과 CPU 옵션을 함께 남겨야 합니다.
실제 튜닝에서는 컴파일된 명령, 대상 CPU·리비전, 앞뒤 의존성, 프런트엔드와 실행 자원 병목을 확인하고 같은 작업량의 지연·처리량을 측정합니다. 이 글은 공식 명령 특성과 모델의 성격을 대조했으며 llvm-mca 실행이나 하드웨어 성능 측정을 수행하지 않았습니다.
출발 자료는 Shreeyash Pandey의 게시물, 원저자 글과 보존 원고입니다. 이번 검토에서 원저자의 실행 화면을 재현한 것으로 기록하지 않습니다. 프로세스 관측 글은 도구의 관측 범위에 관한 관련 글이지 V2 내부 구현 증거가 아닙니다.
English summary. Some Neoverse V2 moves add no execution latency, with documented exceptions. Rename mappings do not remove true producer dependencies or frontend work. llvm-mca reports a scheduling model, not measured silicon performance.