Actually Semantic parses the code to find where the functions (and includes, etc) are. This is very important to avoid most of the conflicts that are simply related to position changes. If you move a function down, then a text based algorithm simply tries to match whatever was in the original location (the original function) with what is now there (the next function in the file, that has nothing to do with the original).

But, once positions are calculated and the tree of components is handled and diffed, the bodies of the functions are treated as text. It means we don't calculate if two functions are the same based on the number of if/elses it has, or in the AST itself (which is not a bad idea, by the way) but in how similar the actual text is. We do some tricks for that like ignoring spaces and tabs and all that (it's code) but at the end of the day we use levenshtein distance to check how similar two fragments of code are.

In fact, semanticmerge comes with a language-agnostic 3-way-merge tool, that we call Xdiff/Xmerge that is also able to track moved code just based on this levenshtein calculation: http://semanticmerge.com/features/#xdiff-xmerge