[cfe-dev] Correspondence between IR and AST branch ways
이광무 via cfe-dev
cfe-dev at lists.llvm.org
Thu Oct 3 01:48:40 PDT 2019
Let me answer to my own question. As far as I searched for, there is no option that forces the front-end not to change the branch way, but you can guess it (i.e., which IR branch way is equivalent to the source code level if statement way) by looking at the basic block labels. These basic block labels are discarded by default, so one may need to specify the ‘-fno-discard-value-names’ compiler option to prevent them discarded. The basic block followed by the taken branches are usually named as ‘%if.then’ in the IR level.
Note that this solution assumes no preliminary optimizations (O0).
Hope this would help anybody.
Regards.
Gwangmu Lee
Ph.D. Student
+82) 10 4114 7441
Room 615, Bldg 301, Seoul National University,
Gwanak-ro 1, Gwanak-gu, Seoul, South Korea.
http://compsec.snu.ac.kr/~gwangmu
________________________________
보낸 사람: 이광무
보낸 날짜: Monday, September 9, 2019 1:00:06 PM
받는 사람: via cfe-dev <cfe-dev at lists.llvm.org>
제목: Correspondence between IR and AST branch ways
Hi all,
I’m currently writing an IR pass that’s required to match a ‘br’ instruction (in IR) with a specific AST if statement. Matching itself can be done quite easily through DebugLoc, but I realized that the ‘way’ (as in where the control flow continues after it’s been (not-)taken) of a branch can be changed in the course of IR optimizations. For example, a branch ‘if (x == 0)’ can be semantically transformed to ‘if (x != 0)’ in the resulting IR.
My question is, how can I know such way-changing transformation has been done on which branches? Or, is there any way I can prevent such way-changes during optimization?
Thanks,
Gwangmu Lee.
Gwangmu Lee
Ph.D. Student
+82) 10 4114 7441
Room 615, Bldg 301, Seoul National University,
Gwanak-ro 1, Gwanak-gu, Seoul, South Korea.
http://compsec.snu.ac.kr/~gwangmu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191003/f36d7805/attachment.html>
More information about the cfe-dev
mailing list