기존 착안점
현재 aload의 경우 load instruction이 또 다른 load, store, phi 또는 mayusememory를 만나면 그 이상 위로 올라가지 못한다.
하지만 load와 절대 메모리가 겹치지 않는 경우, 예를 들어 순차적으로 배열을 접근하는 경우 그 이전 store위로 load를 끌어올릴 수 있다.
기존 최적화
store에 사용되는 pointer operand값이 aload 예정 load instruction과 특정 상수 값만큼 차이가 난다면(a[3]과 a[6]처럼 base pointer가 동일하지만 위치가 다른 경우) store 위로 load를 올릴 수 있으며, 이렇다면 store자체의 cost가 매우 높기 때문에 하나만 찾아도 load cost를 1cost로 줄일 수 있다.
현재 확인사항
현재 aload구현에서 간과한 사실이 발견됨.
작성된 unit test에서는 문제가 발견되지 않았으나, benckmark를 확인해본 결과 문제가 발생.
이유는 모든 load바로 위에 getelementptr instruction이 있고, 이를 통해 load에서 사용되는 operand가 나오기 때문에 더 이상 위로 올라가지 못하게 되어있음.
결국 load instruction은 절대 위로 올라가지 못하는 구조로 되어있고, load를 위로 올리는 코드는 사실 절대 작동될 수 없었던 코드이다
현재 aload의 성능이 약 2~3%밖에 나오지 않고 있는데, load자체의 cost 소모량이 적지 않으며 load를 사용하지 않는 benchmark program은 존재하지 않음에도 불구하고 성능이 너무 낮게 나오고 있었다. 아마 이 이유로 추정된다.
이에 대한 해결방안으로 먼저 getelementptr또한 load처럼 가능한 위로 올리는 방식부터 구현해야 할 것으로 보인다
기존 착안점 현재 aload의 경우 load instruction이 또 다른 load, store, phi 또는 mayusememory를 만나면 그 이상 위로 올라가지 못한다. 하지만 load와 절대 메모리가 겹치지 않는 경우, 예를 들어 순차적으로 배열을 접근하는 경우 그 이전 store위로 load를 끌어올릴 수 있다.
기존 최적화 store에 사용되는 pointer operand값이 aload 예정 load instruction과 특정 상수 값만큼 차이가 난다면(a[3]과 a[6]처럼 base pointer가 동일하지만 위치가 다른 경우) store 위로 load를 올릴 수 있으며, 이렇다면 store자체의 cost가 매우 높기 때문에 하나만 찾아도 load cost를 1cost로 줄일 수 있다.
현재 확인사항
현재 aload구현에서 간과한 사실이 발견됨. 작성된 unit test에서는 문제가 발견되지 않았으나, benckmark를 확인해본 결과 문제가 발생. 이유는 모든 load바로 위에 getelementptr instruction이 있고, 이를 통해 load에서 사용되는 operand가 나오기 때문에 더 이상 위로 올라가지 못하게 되어있음.
결국 load instruction은 절대 위로 올라가지 못하는 구조로 되어있고, load를 위로 올리는 코드는 사실 절대 작동될 수 없었던 코드이다
현재 aload의 성능이 약 2~3%밖에 나오지 않고 있는데, load자체의 cost 소모량이 적지 않으며 load를 사용하지 않는 benchmark program은 존재하지 않음에도 불구하고 성능이 너무 낮게 나오고 있었다. 아마 이 이유로 추정된다.
이에 대한 해결방안으로 먼저 getelementptr또한 load처럼 가능한 위로 올리는 방식부터 구현해야 할 것으로 보인다