2012-01-12 3 views
7

최근 AVM2/AS3 용 디 컴파일러를 만들었습니다. 플래시 컴파일러가 많은 불필요한 코드를 방출하는 경향이 있습니다. 예를 들어, 특정 응용 프로그램의 경우 기능의 손상없이 코드의 약 10 %를 제거했습니다. 그것은 조건부 연산 코드 나 예외 처리 블록에 의해 참조되지 않는 확실히 죽은 코드 일뿐입니다.왜 Flash ActionScript3 컴파일러가 불필요한 코드를 방출합니까?

또한,이 코드를 보면 :

... 
    313  setproperty   y 
    315  getlocal   12 
317 returnvalue 318 jump L9 

    L3: 
    322  getlocal   8 
    324  returnvalue   

    L9: 
325 jump L10 ; L10 (opcode #331) does not ever exist. 
            ; Technically, it is a jump beyond 
            ; the end of function. This is invalid code! 

    L2: 
    329  pushnull    
    330  returnvalue   

음, 물론 이것은 또한 죽은 따라서 (코드베이스 팽만감의 제외) 부작용을 발생하지 않습니다 잘못된 코드입니다. 그런데 왜 그 코드를 방출합니까? 그리고 왜 검증자는 그것을 받아들입니까?

+0

예외 테이블에서 참조되지 않았으므로 (많은 것보다 훨씬 많은 10 가지 지침 - 데드 코드 블록), 스펙에서 판단 할 때 점프 opcode를 통해 제어를 전송할 수 있습니다 또는 예외. 어느 점프도 없습니다. – whitequark

+0

@wvxvw 그런데, 'finally'블록은 AS3에서 이상하고 독창적 인 해킹으로 컴파일됩니다. 컴파일러는 의도적으로 검증자를 속이기 위해 잘못된 opcode를 생성하고 VM은 고의적으로 무시합니다. 플래시는 단지 거대한 WTF입니다. – whitequark

+0

@wvxvw, 내가 너를 올바르게 이해 했니? 특정 연산 코드 시퀀스를 실행하면 실행중인 코드가 opcode 스트림을 어떻게 든 검사 할 수 있습니다. 아마도 데이터 스택으로 푸시하는 것일 것입니다. 참조를 찾을 수 있다면 +50. – whitequark

답변

7

ASC 또는 compc가 최적화되지 않습니다. 이것은 불행한 일이지만 이론은 JIT가 모든 최적화 작업을 수행한다는 것입니다. 두 개의 상수를 추가하는 것과 같은 더 나쁜 예를 생각해 낼 수 있습니다. 그래서 대답은 : 미안하지만, 그냥 최적화하지 않습니다. 앞으로 더 나은 컴파일러가있을 수 있습니다. 지금 당장은 런타임에 최적화 작업을 수행하기 위해 AS3 JIT에 의존해야합니다 (이는 괜찮은 작업입니다!). 또는 다른 컴파일러를 사용하십시오.

+0

예, 물론 불필요한 강제는 말할 것도없고 상수 등을 추가하는 것을 보았습니다. 그것의 최악의 예는 아마'lookupswitch'가 codegen 된 방법 일 것입니다. [LLVM] (http://blog.llvm.org/)과 같은 방식으로 설계된 이유에 대한 언급이 있습니까? 끊임없이 두들겨지지 않는 한 꾸준히 접는 것이 어렵지 않습니다. – whitequark

+1

whitequark : "컴파일러"는 영광스러운 파서 일 뿐이며 JIT는 그 밖의 모든 것을 처리합니다. 나는 개인적으로 그것이 좋은 디자인이라고 생각하지 않지만 그것이 얼마나 좋은지 생각합니다. 나는 좋은 참고도 모르겠다. 미안하다. – starmole