Grant PDF

Departamento de Ciência da Computação
Universidade Federal de Minas Gerais
Geração Eficiente de Código de Qualidade

Geração de Código Energeticamente Eficiente
Proposta submetida ao CNPq para solicitação

de Bolsa de Produtividade em Pesquisa.
Candidato à bolsa: Fernando Magno Quintão Pereira
http://lattes.cnpq.br/4608001746330875
fernando@dcc.ufmg.br
– 5 de julho de 2018 –
Resultados Obtidos Durante Vigência da Última Bolsa de Produ-
tividade em Pesquisa do Proponente (2016-2018)
Esta seção descreve, em 10 linhas, os resultados conseguidos durante os três últimos anos (2016-
2018), perı́odo em que durou a bolsa de produtividade do proponente, atendendo à requisição do
formulário eletrônico de submissão de nova proposta1 .
Em 2016 o proponente teve aceito o projeto “Geração Eficiente de Código de Qualidade – Geração
de Código Seguro”. Durante o perı́odo entre 2016 e 2018, o proponente publicou 8 artigos em
periódico, 15 artigos completos em conferências internacionais e 9 artigos completos em con-
ferências nacionais. Alguns desses artigos foram publicados em veı́culos de alto impacto, como
POPL [65], OOPSLA [83], PPoPP [71], Compiler Construction [92, 29], PACT [86], CGO [80,
53, 62, 103] e ACM TACO [66]. Quatro trabalhos receberam o prêmio de melhor artigo da con-
ferência. Foram executados dois grandes projetos com a indústria: um com a LG Electronics do
Brasil e outro com a Maxtrack. O grupo do candidato produziu centenas de milhares de linhas
de código em ferramentas abertas, que hoje estão disponı́veis publicamente2 . Como reconheci-
mento por suas contribuições cientı́ficas, o candidato recebeu o prêmio Google Research Award in
Latin America em 2017.
Interrupção da Bolsa em 2018

Em novembro de 2017, o candidato solicitou a interrupção de sua Bolsa de Produtividade em
Pesquisa, para que ele pudesse receber uma Bolsa de Pós-Doutorado no Exterior financiada pelo
CNPq. Em 21 de dezembro de 2017 o candidato iniciou suas atividades de pesquisa no Centro
Nacional de Pesquisa Cientı́fica (CNRS), na cidade de Montpellier, França, sob supervisão do
Diretor de Pesquisa Abdoulaye Gamatié. O ano sabático deverá durar até 12 de dezembro de
2018. Findo este perı́odo, o candidato retornará ao Brasil a fim de retomar suas atividades de
ensino e pesquisa na Universidade Federal de Minas Gerais.
1
O formulário eletrônico contém os dizeres: Proponent with current grant, add in the Research project file, at
the top, a maximum 10 lines text describing the goals achieved regarding last proposition. All publications and advi-
sing activities in Lattes CV must be updated.
2
Ferramentas desenvolvidas pelo grupo de pesquisa em compiladores disponı́veis em http://www.cuda.dcc.
ufmg.br
1
Resumo da Proposta
Objetivo: este projeto pertence à área de Linguagens de Programação, sub-área de compilado-
res. Seu objetivo é desenvolver técnicas de código que permitam a produção de programas mais
energeticamente eficientes. Dizemos que um programa P1 é mais eficiente energeticamente que um
programa P2 se P1 produz os mesmos resultados que P1 consumindo menos energia.
Capacidade do proponente: o candidato formou-se doutor em 2008 pela University of Cali-

fornia, Los Angeles. Hoje é professor associado I do Departamento de Computação da UFMG, e
bolsista de produtividade em pesquisa do CNPq. O candidato possui 32 artigos em conferências
internacionais, 44 artigos em simpósios brasileiros, 21 artigos em periódicos internacionais e uma
patente internacional (US 2009/0083721 A1). Nos últimos cinco anos o candidato publicou dois
capı́tulos de livro e 52 artigos completos. Seis desses artigos foram premiados como melhor trabalho
da conferência. Desde seu retorno ao Brasil, o candidato orientou 21 alunos que já defenderam seu
mestrado ou doutorado. Atualmente o proponente orienta seis alunos de mestrado e três alunos de
doutorado. O proponente coordena seis projetos, e participa de outros três. O candidato organizou
diversos eventos cientı́ficos no paı́s: Workshop de Teses do CBSoft em 2013; Simpósio Brasileiro
de Linguagens de Programação em 2014; e o CBSoft em 2015. O CBSoft é o maior congresso de
software do Brasil. Em 2015 ele aconteceu em Belo Horizonte entre os dias 21 e 26 de Setembro.
Descrição: O hardware contemporâneo encontrado em telefones celulares implementa várias ma-

neiras de reduzir seu consumo de energia. Duas dessas técnicas são a combinação de núcleos (cores)
de baixa e alta potência (as arquiteturas chamadas Big.LITTLE) e a capacidade de ajustar dina-
micamente a energia e a velocidade desses núcleos. Esse equipamento deu aos pesquisadores a
oportunidade de projetar métodos para prolongar a vida útil da bateria. Nesta proposta, afir-
mamos que técnicas de economia energética efetivas devem levar em consideração não somente a
natureza do hardware, mas também a natureza da aplicação que otimizam. Assim, propõe-se um
método de compilação de código para decidir, em tempo de execução, a configuração de hard-
ware mais adequada a uma determinada aplicação, em um determinado momento de sua execução.
Uma configuração de hardware consiste em vários núcleos, seu tipo (big ou LITTLE) e seu nı́vel
de freqüência. Para alternar entre configurações, devemos usar o compilador para instrumentar o
programa. Esta instrumentação irá coletar dados de execução e irá combiná-los com informações
estáticas - extraı́das pelo compilador - para selecionar uma configuração de hardware. Técnicas de
aprendizagem de máquina permitirão que o programa se adapte a diferentes cargas de trabalho.
Resultados esperados: Experimentos preliminares já mostram que podemos economizar até
25% do consumo de energia ao preço de uma desaceleração em desempenho inferior a 5%. In-
tencionamos aplicar as técnicas propostas em programas Java que funcionam no sistema Android,
usando Soot, um arcabouço para analisar Java, a fim de instrumentar bytecodes. Acreditamos que
nosso protótipo final permitirá que os desenvolvedores reduzam o consumo de energia de aplicativos
Android a um preço mı́nimo de desempenho. Para demonstrar essa possibilidade, devemos testar
nossas idéias em aplicativos que funcionam em diferentes tipos de smartphones.
Recursos solicitados: solicita-se a renovação da Bolsa de Produtividade em Pesquisa Nı́vel 2

com base na produção técnico-cientı́fica, atuação acadêmica e inserção internacional do proponente.
2
1 Introdução: Eficiência Energética e Compiladores
Uma Arquitetura de Computação Heterogênea é um projeto de hardware que combina diferentes
tipos de processadores no mesmo dispositivo. Arquiteturas modernas de computadores estão se
tornando cada dia mais heterogêneas [119]. O projeto heterogêneo surge através da combinação,
dentro do mesmo hardware, de processadores de alta e baixa frequência [27, 54], aceleradores
(GPUs) [76] e processadores de sinal digital (DSPs) [85]. Uma vantagem deste design é a possibili-
dade de alocar para cada aplicativo a configuração de hardware que melhor lhe convém [83]. Uma
configuração de hardware consiste em vários núcleos, seu tipo e seus nı́vel de freqüência. Dizemos
que uma configuração H1 se adequa a um programa melhor do que outra configuração H2 se H1
executar o programa mais eficientemente do que H2 , de acordo com alguma métrica, como tempo
de execução ou consumo de energia. No entanto, apesar de podermos hoje escolher entre várias
configurações [3], aquela que melhor se adapta às necessidades de um programa, ainda não temos
uma técnica clara para executar esta escolha de forma perfeita.
Muitas vezes, um programa tem regiões de código que se beneficiam de forma diferente de
processadores diferentes. Chamamos a tarefa de alocar partes do programa aos processadores de em
problema de escalonamento. Existem duas maneiras de resolver esse problema: dinamicamente ou
estatisticamente. Abordagens dinâmicas [63, 77, 81] são implementadas em de tempo de execução,
seja através de um sistema operacional, um middleware ou mudanças no próprio programa-alvo.
Abordagens estáticas [66, 78, 71, 82, 83, 113] são implementado no nı́vel do compilador. A principal
vantagem da abordagem dinâmica é o fato de que ela pode se beneficiar de informações de tempo
de execução para melhorar a qualidade das escolhas que ela faz. As técnicas estáticas, por sua vez,
levam a custo de tempo de execução reduzido, e podem se beneficiar de caracterı́sticas do programa.
A grande maioria dessas abordagens tenta acelerar programas; em outras palavras, elas buscam
reduzir o tempo que eles demoram para executar até a conclusão [75]. A energia é muitas vezes
ignorada. Esta omissão é um infortúnio, dada a quantidade de recursos que a indústria coloca
na produção de circuitos que gastam menos energia [115], e de baterias que possuem capacidade
de armazenamento maior [44, 52, 61]. Uma exceção notável a essa tendência é o trabalho de
Nishtala et al. [77]. Esses autores mostraram que reinforcement learning ajuda a encontrar boas
configurações de hardware dadas informações retiradas da execução de programas. A beleza desta
abordagem é a adaptabilidade: os mesmos princı́pios fornecem os meios para explorar um vasto
universo de estados, formado por diferentes configurações de hardware e dados de de execução que
mudam ao longo do tempo. Dado tempo suficiente, e boas heurı́sticas, o algoritmo de aprendizagem
encontra um conjunto de decisões de escalonamento que se adequam ao hardware subjacente. No
entanto, “tempo suficiente”pode ser muito tempo. O universo de possı́veis estados de execução
de um programa é ilimitado e o comportamento de programas é difı́cil de prever sem consultar
o código-fonte. Assim, para acelerar a convergência desses métodos baseados em reinforcement
learning, nós utilizaremos o compilador conforme será explicado na próxima seção.
1.1 Objetivos do Projeto

O objetivo deste projeto é aumentar a duração da bateria de smartphones. Planejamos
alcançar esse objetivo combinando compilação 3 e aprendizagem de máquina. O uso do compilador
torna esta proposta única, distinguindo-a de abordagens anteriores com objetivos semelhantes. O
3
Compilador é o software que traduz programas escritos em linguagens de alto nı́vel, como C, C++ e Java
para código de máquina: seqüências de zeros e uns que o computador entende.
3
compilador nos dá dois benefı́cios. Primeiro, nos permite descobrir as caracterı́sticas do programa
que podemos usar para treinar um algoritmo de aprendizagem de máquina. Este algoritmo apren-
derá como adaptar um programa ao seu ambiente de tempo de execução. Em segundo lugar, o
compilador nos permite instrumentar4 o programa. No contexto desta proposta, a instrumentação
permite que o próprio programa forneça informação ao escalonador5 , sobre qual das suas partes
está atualmente em execução. Com base no conhecimento sobre as caracterı́sticas dessa região do
programa, o escalonador pode tomar ação imediata. Uma ação consiste em escolher uma nova
configuração de hardware para o programa, coletando a recompensa relacionada a essa escolha.
Esse feedback é então usado para ajustar e melhorar as decisões de escalonamento, uma tarefa que
realizamos com uma Rede Neural.
A figura 1 resume a contribuição esperada deste projeto. Queremos produzir uma técnica que os
desenvolvedores de aplicativos podem usar para gerar Programas mais eficientes que serão executa-
dos em smartphones. Nossa técnica não impõe qualquer ônus ao desenvolvedor: ele/ela codificará
seu sistema sem qualquer preocupação sobre como tal sistema será compilado. Da mesma forma,
nossa técnica não terá impacto no uso da aplicação por seus usuários finais. Independentemente
de como o aplicativo foi produzido, seus usuários terão acesso às mesmas interfaces e a mesma
qualidade de serviço. No entanto, é provável que essa aplicação final seja mais eficiente em termos
energéticos; conseqüentemente, prolongando o tempo de vida da bateria do telefone.
1.2 Relevância e Impacto do Projeto

Uma arquitetura de computador heterogênea é formada pela combinação de diferentes processado-
res, que executam em diferentes nı́veis de velocidade e potência [119]. Os smartphones modernos se
encaixam nessa descrição, porque combinam, no mesmo dispositivo, diferentes núcleos, que podem
ser configurados para freqüências diferentes. O modelo big.LITTLE de arquitetura é comum nesse
mundo, dada a crescente necessidade de diminuir o consumo energético de computadores, seja em
dispositivos móveis, seja em grandes centros de processamento de dados. Esse tipo de arquitetura
combina dois tipos de núcleos diferentes: os núcleos de alta potência, chamados big, e os núcleos
de baixa potência, chamados LITTLE. A principal vantagem deste arranjo de hardware é a pos-
sibilidade de alocar para cada aplicação o processador que melhor se adequa a ela. Dizemos que
um processador p1 se adequa a um programa melhor que outro processador p2 se p1 executa o
programa com mais eficiência do que p2 . Nesse caso, eficiência pode ser medida de acordo com uma
determinada métrica, como tempo de execução ou consumo de energia. O projeto big.LITTLE
permeia dispositivos móveis da LG, Samsung e Apple. No entanto, apesar de sua importância,
ainda é difı́cil programar tais dispositivos. O principal desafio, neste caso, é determinar a melhor
configuração de hardware que se encaixa em uma parte especı́fica de um programa, dada uma certa
carga de trabalho. As abordagens atuais de ponta para lidar com este desafio modificam a sistema
operacional. Tal é o caso de Hipster [77] e Octopus-Man [81] - dois sistemas que monitoram a
execução do programa e determinam a melhor configuração para sua execução, dados os resultados
do monitoramento.
As técnicas utilizadas por Hipster e Octopus-Man são dinâmicas: elas dependem de informações
somente disponı́veis em tempo de execução para tomar decisões. A literatura também contém
4
Instrumentação é qualquer forma de código extra que o compilador insere no programa para executar al-
guma ação, como mudar a configuração de hardware em que esse programa executa.
5
Escalonador é o módulo do Sistema Operacional que determina quando e em qual processador, cada pro-
grama deve ser executado.
4
Figura 1: Como os resultados do projeto serão usados.
abordagens puramente estáticas para resolver este problema: o compilador decide onde cada parte
de um programa deve ser executada [55, 66, 83]. Nesta proposta, afirmamos que uma boa solução
para o escalonamento de computações em arquiteturas heterogêneas deve ser hı́brida, envolvendo
o compilador e o sistema operacional. O compilador está ciente da natureza do aplicativo: ele
pode separar e classificar as partes do programa de acordo com as instruções que eles usam ou as
chamadas a funções externas que eles realizam. O sistema operacional, por sua vez, tem acesso
a informações de tempo de execução: a carga de trabalho em cada processador, a duração dos
perı́odos ociosos e o número de threads ativas. Com base nesta observação, propomos a criação de
um sistema de posicionamento computacional para o ambiente de execução Android que reconheça
o aplicativo, se adapta a condições observadas em tempo de execução, e não requeira qualquer
intervenção dos usuários.
5
As técnicas e tecnologias que serão criadas a partir deste projeto são relevantes tanto para a
indústria quanto para a academia. A relevância industrial deve-se à importância que a eficiência
energética assume hoje, entre as mais diversas companhias de hardware e software. Muito esforço
é dispensado à criação de baterias cada vez mais eficientes [118], e à construção de centros de
processamento de dados que consumam cada vez menos energia [95]. A relevância acadêmica deve-
se à crescente importância da eficiência energética na pesquisa hoje. Conferências como ASPLOS,
PLDI e OSDI têm recebido cada vez mais trabalhos sobre o tema, e vários grupos de pesquisa estão
sendo formados em todo o mundo para a investigação de fenômenos relacionados ao consumo de
energia em sistemas computacionais. Recentes esforços nesta direção são, por exemplo, os projetos
Mont Blanc6 na Europa, e o projeto SING7 em Stanford.
2 Resultados Preliminares
Nesta seção, descrevemos os resultados preliminares que reunimos entre Fevereiro de 2017 e Janeiro
de 2018. Estes resultados ainda não foram publicados. Esses resultados vêm demonstrar a
viabilidade do projeto que ora apresentamos. Acreditamos que os dados que apresentaremos nos
permitem chegar as seguinte conclusões:
1. diferentes configurações de hardware levam à compromissos muito diferentes entre consumo
de energia e velocidade de execução para um programa (Fig. 2);
2. estes compromissos diferentes existem porque os programas têm fases de energia: dependendo
das operações que realizam, seu consumo de energia por tempo varia (Fig. 3);
3. a melhor configuração de hardware para um programa pode não atender às necessidades de
uma aplicação diferente (Fig. 4).
Central para a discussão nesta seção é a noção de uma configuração de hardware, que definimos
abaixo:
Definition 2.1 (Configuração de hardware) Uma arquitetura heterogênea é formada por um

conjunto P = {p1 , p2 , . . . , pn } de n processadores. Uma configuração de hardware é uma função
H : P 7→ Boolean. Se H(pi ) = True, então o processador pi é dito ser em ativo em H, caso
contrário, ele é dito ser inativo.
2.1 O Universo de Configurações de Hardware

Observamos que a mesma aplicação pode se beneficiar de forma diferente de diferente configurações
de hardware. Este benefı́cio é medido em termos de tempo de processamento e consumo de energia.
A figura 2 ilustra esse fato. A figura mostra como dois benchmarks do conjunto PARSEC [26]8 -
Freqmine e Streamcluster - se comportam em uma placa Odroid XU3/XU49 . Este hardware possui
4 núcleos Cortex-A15 (2.0Ghz) e 4 núcleos Cortex-A7 (1.4Ghz). Seguindo uma nomenclatura
adotada pela ARM, chamaremos os núcleos A15 bigs, e os núcleos A7 LITTLEs. Ao ligar e desligar
os diferentes núcleos, temos 24 diferentes configurações de hardware10
6
http://montblanc-project.eu/
7
https://sing.stanford.edu/site/projects/9
8
PARSEC é uma coleção de programas normalmente utilizados para testar o desempenho de sistemas de com-
putação.
9
Ambos os modelos, XU3 e XU4, adotam o mesmo processador Samsung Exynos 5422 ARM big.LITTLE
10
Temos 24 = 5 times5 − 1 configurações, porque não contamos a configuração na qual todos os núcleos estão
desligados.
6
12 40
Freqmine 0L1B Streamcluster 4L3B
4L1B
35
3L1B 4L2B
11 30
Energy (joules)
Energy (joules)
1L4B 4L1B 4L1B 4L4B

0L4B 4L4B 25 3L 1L
1L0B 2L 2B 4B 3L3B
4L3B 3B
10 20 2L1B
0L3B
Best Energy/Time 2L 1L3 2L
4B
0L2B 15 2B B
1L1B 2L0B 1L2B
3L0B 1L1B
9 10
Best Runtime
3B
Best Runtime 4L0B
5 1L0B Best Energy
0L
Best Energy 4L0B Best Energy/Time
8 0
0L1B
2.8 3 3.2 3.4 3.6 3.8 4 0 3 6 9 12 15 18 21
Time (secs) Time (secs)
Figura 2: Tempo de energia vs processamento para dois benchmarks PARSEC usando entradas
simsmall. A notação xLyB denota x núcleos LITTLE e y bigs.
Cada ponto na figura representa a média de 10 execuções na mesma configuração, usando a

menor11 entrada disponı́vel no PARSEC. A diferença é quase insignificante, permanecendo abaixo
de 1% em cada amostra, para a dois benchmarks. O eixo X mostra a soma dos tempos de execução
dos processadores ativos em um configuração particular; portanto, não é hora do relógio. A energia
é medida com os contadores de desempenho do Odroid XU3. Essa placa possui um circuito de
medição de potência a bordo, logo, esses números referem-se ao trabalho realizado apenas dentro
dos processadores. Em outras palavras, os periféricos não são considerados.
A figura 2 nos permite concluir que a energia e o tempo de execução de aplicativos varia muito
em diferentes configurações de hardware. Por exemplo, a configuração mais eficiente do tempo
para Freqmine é 0L4B, ou seja, quatro bigs e zero LITTLEs (2.90secs, 10.43J). No entanto, a
configuração mais eficiente em energia é 4L0B (4.01secs, e 8.65J). Os resultados não são os mesmos
para Streamcluster. A melhor configuração de energia é 0L1B (0.48secs, 0.69J). Essa é também
a configuração mais eficiente em tempo. Freqmine mostra mais paralelismo do que Streamcluster;
assim sendo, Beneficia-se mais de um número maior de núcleos. Essa diversidade de cenários
acontece porque os programas têm fases. O comportamento de energia e tempo de execução é
semelhante na mesma fase e potencialmente diferente em diferentes fases. Na próxima seção,
analisamos esta hipótese mais profundamente.
2.2 Fases de Programas

A potência instantânea consumida por um programa nem sempre é constante. Em outras palavras,
um programa tem fases de energia. Para demonstrar esse fato, devemos considerar o programa
na figura 3. Esse é um exemplo artificial criado para enfatizar as diferentes fases pelas quais um
programa passa durante a sua execução. Esse programa executa as seguintes ações: (i) lê duas
matrizes de arquivos de texto; (ii) as multiplica e (iv) imprime todas as matrizes na saı́da padrão.
Entre cada uma dessas ações, colocamos comandos para ler dados da entrada padrão.
A figura 3 (e) mostra o perfil de energia deste programa. Este gráfico foi produzido com
11
Esta experiência leva aproximadamente 12 dias usando as maiores entradas.
7
public int foo(String[] argv) {
8 (e)
int M1, N1, M2, N2; readMatrix
// Read first matrix from file 'argv[1]' mulMatrix printMatrix
int[][] m1 = readMatrix(argv[1], M1, N1); 6
(c) read_user_data();
// Read second matrix from file 'argv[1]'
read_user_data(); 4
int[][] m2 = readMatrix(argv[2], M2, N2);
(a) read_user_data();
2
Power (W)
// Multiply both matrices, giving m3
6
int[][] m3 = mulMatrix(m1,m2,M1,N1,N2);
read_user_data(); 0
// Print all the matrices in the 0 50 100 150 200 250 300 350 400
// standard output Time (msec)
4
printMatrix(m1, M1, N1);
(b)
read_user_data();
} (d) 2 (f) big LITTLE
Figura 3: (a) A placa Nvidia TK1. (b) Dispositivo de aquisição de dados NI 6009. (c) Cir-
cuito de sincronização. (d) Multiplicação de matrizes implementada em C. (e) Perfil de potência
desse programa. A taxa de amostragem NI 6009 foi de 1000 amostras/seg. (f) Zoom do perfil de
potência obtido durante a última fase do programa. Mostramos dados de energia obtidos usando
um núcleo de baixa freqüência (LITTLE) e usando um núcleo ARM A15 (big).
JetsonLeap [24], um aparelho que nos permite medir a energia consumida pelos programas que
funcionam na placa Nvidia TK1 Jetson12 . O JetsonLeap é formado por três componentes: a
placa Nvidia (Figura 3 (a)), um dispositivo de aquisição de dados, que lê a potência instantânea
consumida pela placa (Figura 3 (b)), e um circuito de sincronização, que nos permite comunicar
ao aparato de medição qual evento de programa está sendo executado em cada instante (Figura 3
(c)).
Existem fases distintas dentro do mesmo programa porque ele pode usar o hardware de formas
diferentes, dependendo de qual parte está sendo executada. Ao ler contadores de desempenho,
sabemos que durante a multiplicação da matriz, a CPU está no seu uso máximo. Durante as
operações de entrada/saı́da, esta utilização cai levemente, e outros componentes do hardware,
como a sua porta serial, são mais usados. Essa queda é ı́ngreme uma vez que o programa está
aguardando as entradas do usuário. A CPU não é o único componente de hardware que explica
a dissipação de energia. O aparelho JetsonLeap mede a energia para todo o hardware. Assim, a
sub-utilização da CPU não significa que o consumo geral de potência diminuirá. No entanto, as
variações no uso da CPU provavelmente causarão variações no perfil de energia do programa.
Descobrir essas fases do programa por meio de técnicas puramente dinâmicas é possı́vel, mas
difı́cil. Poderı́amos, em princı́pio, usar profiling, à la Hipster [77], para identificar variações em
comportamento do programa. No entanto, essa abordagem tem duas deficiências. Primeiro, partes
distintas do programa, com diferentes demandas em termos de memória, CPU, e disco, podem
exibir caracterı́sticas dinâmicas semelhantes. Por exemplo, poderı́amos imaginar um cenário em
12
Nesta seção usamos duas configurações experimentais: Odroid XU4 e Tegra TK1. A primeira nos dá a riqueza
de configurações vistas na figura 2. Essa diversidade está ausente na última. Contudo, a placa TK1 nos dá acesso à
JetsonLeap, e, consequentemente, à capacidade de medir energia por eventos de programação.
8
que a função read user data, na figura 3 é implementada via espera ocupada. Nesse caso, em vez
dos vales observados na figura 3 (e), encontrarı́amos uma linha de energia semelhante à produzida
por pela função mulMatrix. Em segundo lugar, as técnicas baseadas em profiling enfrentam uma
tensão entre precisão e sobrecarga. A detecção precisa exige altas taxas de amostragem; sobrecarre-
gando o aplicativo que originalmente pretendı́amos otimizar. No entanto, as abordagens puramente
estáticas não são melhores. Embora seja provável que produzam custos gerais de adaptação mais
baixos, elas não conseguem lidar com informação disponı́vel apenas em tempo de execução, como
tamanhos de entrada de dados. Por exemplo, uma instrumentação estática pode decidir sempre
executar mulMatrix e read user data em diferentes configurações. No entanto, ao operar em matri-
zes pequenas, o custo de mudar a a configuração de hardware já pode ofuscar os possı́veis ganhos
disponı́veis através de um uso mais parcimonioso dos recursos da arquitetura.
2.3 Em Busca da Configuração Ideal de Hardware

Os dados apresentados nesta seção demonstram que a melhor configuração de arquitetura, em
termos de tempo de execução ou consumo de energia, difere entre os programas. A figura 4 mostra
as melhores configurações encontradas no Odroid XU4, para seis diferentes aplicativos PARSEC.
Nesse caso, definimos a melhor configuração como a que gasta menos energia, dada uma certa
desaceleração em comparação com a configuração mais rápida. Claramente, não há um único
vencedor. As configurações variam entre os programas, e mesmo dentro do mesmo programa, dado
diferentes nı́veis de desaceleração aceitáveis.
No restante desta proposta, descreveremos uma metodologia geral que pretendemos usar para
encontrar boas configurações de hardware para as funções invocadas durante a execução de um
programa. Nesta seção, destacamos a motivação chave por trás do nosso projeto: (i) um hardware
heterogêneo moderno expõe uma série muito grande de diferentes configurações para serem avali-
adas manualmente; (ii) um programa apresenta fases de potência, que podem ser mais facilmente
detectadas por métodos que estão cientes de propriedades estruturais do código. Assim, afirmamos
que a adaptação efetiva exige conhecimento de caracterı́sticas do programa. Essa informação está
prontamente disponı́vel para o compilador, e é difı́cil ser adquirido sem o seu apoio.
3 Metodologia
Um projeto de três anos. Este documento descreve um projeto de 3 anos. As seções 3.1-3.3
descrevem o plano de trabalho para o primeiro ano. A seção 3.4 descreve o plano de trabalho
para os dois anos seguintes. Optou-se por dar maior detalhe ao primeiro ano do projeto porque
os resultados conseguidos nesta fase irão contribuir para os dois anos posteriores. Temos uma
visão clara do que precisa ser feito neste primeiro ano – o trabalho que será desenvolvido nos dois
anos seguintes, contudo, é ainda passı́vel de mudanças, as quais serão necessárias para ajustar a
metodologia de investigação aos resultados encontrados.
O produto final – uma prova de conceito. Ainda assim, o objetivo prático do projeto é bem
definido, e não irá mudar durante a sua execução. Tal objetivo é entregar uma implementação
de protótipo que reduz o consumo de energia em programas Android. Este protótipo seguirá o
modelo visto na Figura 5. O objetivo geral deste projeto é prolongar a vida útil da bateria dos
9
3
facesim
freqmine
blacksholes
ferret
facesim
Number of big cores in use
2
freqmine
blacksholes bodytrack
ferret
vips
bodytrack
1
vips
5% loss
streamcluster
1% loss
streamcluster
0
0 1 2 3
Number of LITTLE cores in use
Figura 4: As melhores configurações para sete aplicativos PARSEC, dado um nı́vel aceitável de-
saceleração de 1% ou 5% em comparação com a configuração mais rápida.
smartphones. Devemos atingir esse objetivo ao resolver um desafio que chamamos de Problema do
Agendamento em Arquiteturas Heterogêneas, que definimos da seguinte forma:
Definition 3.1 Escalonamento de Programas em Arquiteturas Heterogêneas ( SPha)

Input: um programa P mais sua entrada I, um conjunto de configurações de hardware H1 , H2 , . . . Hn ,
um limite de energia E e uma performance limite S.
Output: P 0 , uma nova versão de P , que alterna entre configurações usando E% menos energia,
com uma desaceleração de não mais do que S%.
Pretendemos resolver SPha usando uma variedade de técnicas diferentes, que, uma vez combi-
nados, nos dê os meios para gerar um código bem adaptado a diferentes arquiteturas e cargas de
trabalho. A figura 5 coloca essas técnicas em perspectiva. Devemos usar o framework de compilação
Soot [112] para analisar um programa, extraindo os recursos que acreditamos serem fundamentais
para o seu comportamento de potência. Esta etapa é chamada de “Program Instrumentation”na
Figura 5. Devemos usar esses recursos para treinar uma Rede Neural (NN), em um outro passo
chamado “Actuation”na figura 5. Nossa rede neural deve receber informações dinâmicas e estáticas.
10
Essa última parte é formada exatamente pelos recursos extraı́dos na “Instrumentação”. O compo-
nente dinâmico é dado pelo status de contadores de desempenho de hardware: unidades pequenas
que registram importantes eventos de hardware, como o uso da CPU, a dissipação de energia e
padrões de acesso à memória. Finalmente, ao treinar a Rede Neural, usaremos o conhecimento im-
presso em seus neurônios para produzir o código binário que deve ser implantado no smartphone.
Essa fase é chamada de “Final code generation”na Figura 5. No restante desta seção, descreveremos
as etapas envolvidas neste projeto.
3.1 Objetivo 1: Extração de Caracterı́sticas

Hipótesis de Trabalho É possı́vel enumerar os recursos que acreditamos serem essenciais para
determinar o comportamento de potência de um programa Android, lendo seu código fonte.
Rationale Exemplos de caracterı́sticas do programa incluem o número e a qualidade das instruções
que o programa usa, as bibliotecas chamadas, e a estrutura geral de seu gráfico de fluxo de controle.
Sabe-se que tais caracterı́sticas determinam o tempo de execução do programa [1, 21]. Os resultados
da Seção 2 indicam que essas caracterı́sticas também determinam o comportamento energético do
programa.
Metodologia Devemos usar o arcabouço de compilação Soot [112] para executar essa extração.
Esta etapa corresponde à “Program Instrumentation”na Figura 5.
Resultados Esperados A construção automática de uma versão instrumentada do programa, que
irá reportar ao atuador (o assunto da Seção 3.2) qual conjunto de recursos estão atualmente em
avaliação durante a execução do programa.
Análise de Riscos 1% - Esta é a etapa de menor risco do projeto, porque já temos fortes evidências
que caracterı́sticas sintáticas do programa determinam seu comportamento de potência, como visto
Figura 5: O protótipo a ser produzido no primeiro ano deste projeto.
11
na Seção 2. No entanto, existe uma pequena probabilidade de que, independentemente de como o
programa está escrito, seu comportamento de potência permaneça o mesmo. Este resultado já seria
importante, porque contradiz décadas de intuição na análise e otimização de códigos; no entanto,
ele poderia comprometer substancialmente nosso projeto. Se for esse o caso, devemos usar apenas
as caracterı́sticas de tempo de execução para otimizar o comportamento de potência do programa,
em vez de seus recursos sintáticos.
Significado Após este estágio, teremos uma avaliação de quais caracterı́sticas sintáticas de pro-
gramas determinam seu perfil de potência. Este resultado já é útil para a indústria, pois os desen-
volvedores podem usar esse conhecimento para reduzir o consumo de energia de seus programas.
3.2 Objetivo 2: Adaptação do Programa

Hipótesis de Trabalho Se executarmos um programa o suficiente, e coletar dados de tempo de
execução relacionados a cada uma dessas execuções, então podemos treinar a rede neural persona-
lizada na Seção 3.1, para modelar corretamente o comportamento de potência de um programa.
Esta rede neural pode prever, para cada região do programa, a melhor configuração de hardware
que se adapte a essa região.
Rationale A aprendizagem de reforço demonstrou ser capaz de prever o comportamento de siste-
mas complexos [106]. No nosso caso, a quantidade de dados disponı́veis para a previsão, juntamente
com a dinâmica de tempo de execução de um programa, nos leva a acreditar que uma rede neural
é a melhor tecnologia disponı́vel para modelar as muitas idiossincrasias desse sistema.
Metodologia Este estágio corresponde à fase “Actuation”na Figura 5. Devemos usar Q-Learning [117],
um tipo particular de método de aprendizagem de máquina para modelar o comportamento dos
programas. Devemos manter o programa funcionando em uma placa de desenvolvimento e imple-
mentar o atuador em um chip separado, para que possamos minimizar a interferência do atuador
no programa que queremos treinar. A comunicação entre o programa e o atuador deve acontecer
em perı́odos configuráveis via uma conexão ethernet rápida.
Resultados Esperados Uma tabela que relaciona os recursos do programa com a melhor ação a
ser realizada. Uma ação é uma configuração de hardware que deve ser adotada, dado esses recursos.
Análise de Riscos 5% - É possı́vel que o volume de fragmentação dos dados de um programa
torne o treinamento impraticável. Acreditamos que esta possibilidade não é provável, pois o Q-
Learning foi usado para treinar sistemas relativamente mais complicados, como o comportamento
de pintores, por exemplo [60]. No entanto, devemos usar a maior parte do ano para efetivamente
treinar uma rede neural para prever as ações susceptı́veis de minimizar o comportamento energético
de programas. Se falharmos, devemos estudar quais caracterı́sticas de um programa em execução
impedem uma rede neural de prever seu comportamento. Acreditamos que esse tipo de incerteza
será útil para os cientistas, pois dará pistas sobre os limites do aprendizado de reforço e sobre as
caracterı́sticas dinâmicas dos programas.
Significado Se formos bem sucedidos, teremos demonstrado que o comportamento de potência
de um programa pode ser previsto automaticamente por meio de uma inteligência artificial. Esta
observação provavelmente levará outros grupos de pesquisa a ampliarem nossos resultados, pois são
importantes para a geração de programas mais eficientes.
12
int main(int argc, char** argv) { int main(int argc, char** argv) { int main(int argc, char** argv) {
save_feature_ranges ( /* Conf == 1 is 0L1B */ /* Conf == 1 is 0L1B */
0.12, /* Arithmetic Density */ determine_active_configuration (1); Perf = read_perf_counters();
0.8, /* IO weight */ // Read first matrix from file 'argv[1]' choose_active_configuration (Perf);
0, /* Nesting factor */ int** m1 = readMatrix(argv[1],&M1,&N1); // Read first matrix from file 'argv[1]'
False /* Sleeping state */ ); /* Conf == 0 is 1L0B */ int** m1 = readMatrix(argv[1],&M1,&N1);
// Read first matrix from file 'argv[1]' determine_active_configuration (0); /* Conf == 0 is 1L0B */
int** m1 = readMatrix(argv[1],&M1,&N1); read_user_data(); Perf = read_perf_counters();
toggle_sleeping_state ( /* Conf == 1 is 0L1B */ determine_active_configuration (Perf);
True /* Known blocking function */ ); determine_active_configuration (1); read_user_data();
read_user_data(); // Read second matrix from file 'argv[1]' /* Conf == 1 is 0L1B */
toggle_sleeping_state ( ... same as original figure. Perf = read_perf_counters();
False /* Back into activity */ ); } determine_active_configuration (Perf);
// Read second matrix from file 'argv[1]' // Read second matrix from file 'argv[1]'
... same as original figure. ... same as original figure.
} (a) (b) } (c)
Figura 6: Os diferentes tipos de instrumentação que devemos usar para gerar código eficiente em
termos de energia para ser implantado em dispositivos reais. (a) Instrumentação criada na pri-
meira fase do projeto (Sec. 3.1). (b) Código gerado com agendamento fixo determinado após o
treinamento. (c) Código gerado com agendamento baseado em decisões de tempo de execução
que usam conhecimento aprendido para escolher a próxima configuração de hardware.
3.3 Objetivo 3: Geração final do código

Hipótesis de Trabalho É possı́vel produzir versões binárias de aplicativos Android que usam o
conhecimento de adaptação adquirido na Seção 3.2 para escolher, em tempo de execução, confi-
gurações de hardware que levam a um menor consumo de energia.
Rationale Intuitivamente, entendemos que as ações realizadas durante a fase de treinamento de
nosso sistema pode ser enxertada no código binário do programa. Assim, se o treinamento ocorrer
durante um perı́odo suficientemente longo, a rede neural converge para um estado que nos permite
prever o comportamento de potência dos programas, independentemente da complexidade desses
programas.
Metodologia Esta parte do projeto corresponde ao estágio “Final Code Generation”na Figura 5.
Para gravar o resultado do treinamento sobre o programa, devemos modificar o código que o
compilador produz para esse programa. Essa modificação consiste em declarações, inseridas no
inı́cio de cada função, para determinar a configuração de hardware onde essa função deve ser
executada. A figura 6 mostra os diferentes tipos de instrumentação que pretendemos testar13 . Elas
diferem em termos de precisão e sobrecarga de tempo de execução.
Resultados Esperados Neste ponto, esperamos que os programas finais que produzimos sejam
mais energeticamente eficientes do que as versões originais desses programas. Esperamos economizar
5X% de energia, dada uma desaceleração de X%, até 25% de economia de energia no melhor dos
casos, e com uma média de 2-5% de economia de energia em aplicações tı́picas.
Análise de Riscos 25-35% - Esta é a fase mais arriscada do projeto, porque não temos resultados
preliminares que indicam que é possı́vel desconectar um programa de sua rede de treinamento, tal
13
O código em negrito nestes exemplos é apenas para o propósito de ilustrar nossas idéias. Este código não
existe hoje. Durante este projeto, implementaremos formas semelhantes de instrumentação.
13
que ele ainda seja capaz de se adaptar às condições de tempo de execução, com base apenas no
conhecimento adquirido durante o treinamento. Intuitivamente, isso deve ser possı́vel, porque vários
grupos de pesquisa já mostraram que tal adaptação é possı́vel para tempo de execução [81, 77] (mas
não para energia). O principal problema que esperamos enfrentar é a sobrecarga da instrumentação:
é possı́vel que o custo da verificação das condições de tempo de execução - pago em termos de
instruções extras executadas - reduza muito os ganhos da adaptação. O número de estratégias
diferentes que podemos usar para tentar reduzir esse custo é enorme, e esperamos gastar bastante
esforço para encontrar as melhores alternativas ao longo dessa direção. Se falharmos, pelo menos,
poderemos mostrar que essa instrumentação de código consciente de energia exige metodologias
ainda não existentes, nem na indústria, nem na academia.
Significado Se for bem sucedido, após essa terceira fase do nosso projeto, teremos demonstrado
que é possı́vel reduzir o consumo de energia de programas de forma completamente automática, ou
seja: sem a intervenção de desenvolvedores de aplicativos ou usuários de aplicativos. Esse baixo
custo humano proporciona um grande incentivo para que nossas idéias sejam adotadas na indústria.
3.4 O Projeto Extendido – Anos 2 e 3

No primeiro ano do projeto, queremos decidir a melhor configuração de hardware para um dado
aplicativo e um dado smartphone. No entanto, nossa visão é mais grandiosa: nós vivemos em
um mundo imerso em dispositivos computacionais. Todo dispositivo hoje tem um processador e
esses processadores podem ser muito diferentes. Assim, qualquer dispositivo conectado à Internet
tem acesso a uma infinidade de diferentes configurações de hardware. Nossa visão é que devemos
ser capazes de escolher boas configuração de hardware para as diferentes aplicações que as pessoas
usam em suas atividades diárias. Para este fim, os aplicativos devem migrar para processadores não
necessariamente dentro do mesmo microchip, como GPUs e DSPs. Mais ainda: eles devem migrar
para hardware disponı́vel na nuvem. Assim, vislumbramos um mundo no qual o compilador pode
traduzir partes da mesma aplicação de forma independente para diferentes tipos de processadores.
A figura 7 resume essa visão. Caso tenhamos este projeto aprovado, então esperamos alcançar
a visão descrita na figura 7 em três passos, que nós descreveremos brevemente no restante desta
seção.
Passo 1 – Medição de Energia em Sistemas Distribuı́dos: Vamos desenvolver uma infra-

estrutura, semelhante ao nosso JetsonLEAP [25], que nos permite medir a energia total gasta por
um sistema formado por um smartphone mais um servidor em execução na nuvem. Este sistema
deve nos fornecer os meios para aplicar as técnicas desenvolvidas no primeiro ano deste projeto em
sistemas distribuı́dos.
Critério de sucesso: a implantação de um aparelho que nos permita medir a quantidade de energia
gasta em intervalos regulares por um smartphone que se comunica com um servidor remoto.
Desafio principal: a latência da rede. Medir energia gasta dentro de um único dispositivo não é
difı́cil, e nós fizemos isso já com sucesso, como visto na Seção 2. No entanto, medir a energia gasta
em uma rede é mais difı́cil, porque envolve a consideração da latência da comunicação.
Análise de Risco: 5% - o risco nesta etapa é pequeno, porque nós temos experiência em projetar
artefatos de medição de energia [24, 25, 75, 111], e nós esperamos contar com o apoio de um
engenheiro profissional no segundo ano deste projeto.
14
Figura 7: Queremos implementar compiladores que sejam capazes de traduzir diferentes partes
de um programa para diferentes processadores, incluindo hardware disponı́vel na nuvem.
Passo 2 – Descarga Manual de Código: Vamos estender as técnicas vistas no primeiro ano do
projeto para levar processadores off-chip14 em consideração. Um processador off-chip é qualquer
recurso de computação localizado fora do microchip do dispositivo que executa a aplicação de
interesse. Esses processadores incluem unidades de processamento gráfico (GPUs), processadores de
sinal digital (DSPs) e até mesmo processadores distribuı́dos, como serviços em nuvem. Neste ponto,
usaremos bibliotecas feitas à mão para implementar a descarga de trabalho de um processador em
outro.
Critério de sucesso: a capacidade de migrar cálculos entre processadores a fim de aumentar a
duração da bateria do dispositivo.
Desafio principal: o custo de mover dados para fora do chip pode ofuscar os ganhos derivados
do próprio descarregamento.
Análise de Risco: 15% - se o primeiro ano deste projeto for bem sucedido, não há razão para
acreditar que não podemos estender o treinamento metodologia para adaptar os programas a um
ambiente mais rico em dispositivos computacionais.
Passo 3 – Descarga Automática de Código: Vamos implementar um compilador que possa

gerar código para ser descarregado para processadores externos. Para tal fim, seguiremos uma
metodologia já em vigor na indústria: o uso de sistemas de anotações que permitam aos desen-
14
Optou-se por utilizar o termo em inglês para denotar sistemas computacionais constituı́dos por vários proces-
sadores em uma mesma máquina, mas não no mesmo micro-chip.
15
volvedores marcar o código que pode ser descarregado. Tais sistemas incluem OpenMP 4.0 [57],
OpenSs [64], e OpenACC [67, 66]. Várias dessas anotações já possuem compiladores que as su-
portam; contudo, a nuvem ainda é um desafio: não existe suporte para a produção automática de
código que é executado em servidores remotos. Esperamos lidar com esse desafio nesta etapa.
Critério de sucesso: a geração automática de código que é executado em diferentes tipos de
processadores; em particular, que são executados na nuvem.
Desafio principal: a indisponibilidade de ferramentas que suportam o geração de código que
pode ser transferido para dispositivos externos, como servidores disponı́veis na nuvem. Risk As-
sessment: 30% - nossa experiência com projeto e implementação de compiladores nos permite
saber que a construção de um compilador é um difı́cil esforço. Não temos dúvidas de que podemos
executar essa tarefa até a conclusão, dado tempo suficiente. Ainda assim, é possı́vel que no final
do perı́odo de três anos, tenhamos um compilador que ainda é muito preliminar para ser liberado
para o público em geral.
3.5 Cronograma
Esta proposta descreve um projeto de três anos, composto das atividades descritas na seção anterior.
O cronograma esperado para cada uma dessas atividades está descrito no gráfico de Gantt da
figura 8
Ano Ano 1 Ano 2 Ano 3

Mês 1 2 3 4 5 6 7 8 9 10 11 12 13-24 25-36
Extração de
Objetivo 1
Características
Adaptação de
Objetivo 2
Programas
Geração de Código
Objetivo 3
Instrumentado
Passo 1
Segunda
Passo 2
fase
Passo 3
Figura 8: Cronograma esperado para o projeto.
3.6 Infra-Estrutura Existente

O presente projeto, caso aprovado, será desenvolvido nas dependências do Departamento de Ciência
da Computação da UFMG, pelos integrantes do Grupo de Pesquisa em Compiladores. A UFMG
é uma das cinco maiores universidades do Brasil, sendo a maior universidade federal do paı́s. Ela
oferece 75 cursos de graduação, 57 programas de doutorado, 66 programas de mestrado, 79 progra-
mas de especialização e 38 programas de residência médica. A universidade tem uma população
de 49,254 estudantes (2015). O Departamento de Ciência da Computação foi fundadao em 1966, e
desde o seu inı́cio, seu programa de pós-graduação concedeu mais de 1000 diplomas de mestrado e
mais de 150 diplomas de doutorado. O departamento tem 65 professores, e está classificado entre
os cinco primeiros do Brasil, pelo Ministério da Educação (de acordo com a CAPES).
O grupo de compiladores é coordenado por Fernando Pereira. Esse grupo conta com cerca de 20
pesquisadores, entre assistentes de graduação, mestrado, doutorado e pós-doutorado. Esta equipe
16
Figura 9: Dependências do DCC-UFMG onde será realizado o projeto proposto.
tem sido capaz de publicar artigos nas principais conferências como OOPSLA, PACT, PLDI, CGO
e Compiler Construction. A equipe de investigação tem acesso a três servidores com mais de 60
núcleos disponı́veis para a execução de experimentos. Além disso, o grupo conta com 12 estações
de trabalho, e seis laptops que os alunos podem usar. Dois desses servidores têm GPUs. Estão
disponı́veis também duas placas Nvidia TK1 com núcleos ARM mais GPUs, além de todo o aparato
para a realização de experimentos de medição de energia. Além disso, o Departamento de Ciência
da Computação tem um grande cluster de computadores para a realização de experimentos em
computação de alto desempenho. A figura 9 mostra a sala em que trabalham os integrantes do
grupo.
Afora esses recursos, os pesquisadores que trabalham no Departamento de Ciência da Com-
putação da UFMG têm acesso a salas de conferências para reuniões remotas, uma biblioteca bem
fornecida, cinco auditórios, e contam com o apoio de uma equipe administrativa muito eficiente.
Além de toda essa infra-estrutura, a equipe possui ainda o conhecimento e o material necessário
para efetuar medições de energia em hardware embarcado. Essa tecnologia, chamada JetsonLeap,
vem sendo desenvolvida pela equipe de pesquisadores desde 2014, e encontra-se hoje disponı́vel
como software livre, no link: http://cuda.dcc.ufmg.br/jetson/.
4 Resultados Esperados
Cada uma das fases descritas na seção 3 deste documento contém uma breve descrição de resultados
esperados. Atendendo a recomendações do Edital 09/2018, resumimos aqui tais resultados.
Contribuição técnica. Experimentos preliminares já mostram que podemos economizar até 25%
do consumo de energia ao preço de uma desaceleração em desempenho inferior a 5%. Intencionamos
aplicar as técnicas aqui propostas em programas Java que funcionam no sistema Android, usando
Soot, um arcabouço para analisar Java, a fim de instrumentar bytecodes. Acreditamos que nosso
protótipo final permitirá que os desenvolvedores reduzam o consumo de energia de aplicativos
Android a um preço mı́nimo de desempenho. Para demonstrar essa possibilidade, devemos testar
nossas idéias em aplicativos que funcionam em diferentes tipos de smartphones.
Para uma visão global da aplicabilidade dos resultados deste projeto, referimos o avaliador à
figura 1. Técnicas que reduzem o consumo de energia de programas que executam em aparelhos
celulares tem emprego imediato na indústria de ponta. Prova disso é o fato de o proponente já
17
coordenar, ou ter coordenado, projetos com objetivos semelhantes, financiados pela LG Electronics
e pela Google. E, posto que aparelhos modernos possuem formas cada vez mais agressivas de
modificação de frequência de execução, acredita-se que essas técnicas serão cada vez mais úteis.
Produção bibliográfica esperada. Esperamos que desse projeto resultem várias publicações
de natureza cientı́fica. Em particular, cada uma das fases descritas na seção 3 pode dar-nos opor-
tunidade de publicar diferentes trabalhos em periódicos e conferências de prestı́gio em ciência da
computação. Findos os três anos de projeto, esperamos termos publicado:
• [Perı́odicos]: pelo menos seis artigos em periódicos A1 ou A2.
• [Conferências internacionais]: pelo menos seis artigos em conferências internacionais Qua-

lis A1 ou A2.
• [Conferências nacionais]: pelo menos nove artigos em conferências nacionais.
Formação esperada de recursos humanos. Esperamos, ao final deste projeto, termos orien-
tado alunos em nı́vel de graduação e pós-graduação. Assim, em termos de formação de recursos
humanos, esperamos ter contribuı́do para a educação cientı́fica de:
• [Graduação]: quatro alunos de iniciação cientı́fica.
• [Mestrado]: cinco alunos de mestrado.
• [Doutorado]: dois alunos de doutorado.
5 Compilação de Atividades de Pesquisa Desenvolvidas

Essa seção, e as duas próximas seções deste documento buscam atender o item 6.6.1.f do edital
CNPq 09/2018, que pede:
Compilação sucinta das atividades de pesquisa desenvolvidas, consideradas pelo requerente
as mais relevantes, indicando a produção gerada por elas até 2018. Tais atividades podem
ser demonstradas por intermédio de artigos cientı́ficos, capı́tulos de livros ou livros, trabalhos
completos em eventos cientı́ficos, patentes, softwares, documentos que subsidiaram a elaboração
de leis e/ou implementação de polı́ticas públicas, entre outros. Também podem ser mencionados
financiamentos recebidos de agências públicas ou instituições privadas, orientações concluı́das
ou em andamento e parcerias institucionais;
A fim de que o avaliador CNPq tenha subsı́dios para apreciar a qualidade e quantidade da
produção de Fernando Pereira, esta seção apresenta suas contribuições intelectuais. Sua produção
é representada por publicações cientı́ficas e ferramentas de software disponı́veis para usufruto da
sociedade. Adota-se por referência a metodologia da CAPES a fim de classificar a produção do
docente. Começa-se a discussão da produção intelectual do docente apresentando-se uma breve
descrição da pesquisa que ele realizou (Sec. 5.2.1) durante sua formação e que vem realizando na
UFMG (Sec. 5.2.2). Números e métricas relacionadas a essa produção são analisados na Seção 5.3.
Antes, contudo, de passar-se à discussão da produção de Fernando Pereira, a Seção 5.1 provê ao
leitor uma breve perspectiva sobre a área em que Fernando faz pesquisa: os compiladores.
18
5.1 A Pesquisa em Compiladores em Perspectiva
Fernando Pereira realiza pesquisa em compiladores – um subcampo da área de Linguagens de
Programação. Um compilador é o software que traduz um programa que o desenvolvedor escreve
em uma linguagem de programação para um programa escrito em linguagem de máquina. A fim
de que a pesquisa realizada por Fernando seja colocada em perspectiva, convém ressaltar que:
1. Compiladores estão entre as ferramentas mais antigas desenvolvidas por cientistas da com-
putação. A linguagem Fortran, por exemplo, já possuia um compilador em 1958 [22].
2. Compiladores são essenciais para a ciência da computação, pois eles aumentam a produti-
vidade dos programadores. Caso programas ainda fossem feitos em linguagem de máquina,
dificilmente terı́amos avanços como a Internet, os sistemas operacionais, os bancos de dados,
etc [2].
3. Pouco software recebe tanto investimento da indústria básica de informática (Intel, IBM,
Google, Facebook, etc), como os compiladores, devido à sua importância [56].
4. Compiladores e linguagens de programação são os temas que mais conferiram Prêmios Turing
ao longo da história da ciência da computação. O Prêmio Turing é a homenagem mais
importante que um cientista da computação pode receber. Dentre os pesquisadores da área
de compiladores que já ganharam o prêmio, cita-se: Alan Perlis, John McCarthy, Dana Scot,
John Backus, Robert Floyd, Kenneth Iverson, C.A.R. Hoare, Dennis Ritchie, Nicklaus Wirth,
John Cocke, Robin Milner, Kristen Hyggard, Ole-Johan Dahl, Alan Kay, Fran Allen e Barbara
Liskov.
5. Existem somente quatro conferências na área de linguagens de programação classificadas como

A1 pelo Qualis de Conferências. Todas essas conferências possuem taxa de aceitação inferior
a 25%.
6. Não existem periódicos na área de linguagens de programação classificados como A1. O

periódico melhor classificado é o ACM Transactions on Programming Languages and Systems
(TOPLAS): uma revista A2.
A partir desses pontos, conclui-se que a pesquisa em compiladores é importante. Porém, uma
vez que trata-se de uma ferramenta antiga, a pesquisa é difı́cil. A publicação de bons resultados
leva tempo, pois faz-se necessário competir contra ferramentas industriais. Uma vez que a pesquisa
é difı́cil, e já bastante sedimentada, ela ainda é incipiente no Brasil. Testemunho disso é o fato de,
dentre os autores dos últimos três Simpósios Brasileiros de Linguagens de Programação (SBLP),
somente três possuirem bolsa de produtividade (incluindo Fernando Pereira). Todas essas bolsas
são nı́vel 2. Assim, é a luz de tais fatos que espera-se que a leitura da produção intelectual de
Fernando seja feita.
5.2 Pesquisa Comentada

Esta seção analisa as principais contribuições cientı́ficas de Fernando Pereira, seja no perı́odo de
sua formação (Seção 5.2.1), seja durante seu termo enquanto professor adjunto do DCC-UFMG
(Seção 5.2.2).
19
5.2.1 Perı́odo Pré-UFMG
Graduação. A primeira tentativa de Fernando Pereira de fazer qualquer trabalho em linguagens
de programação foi orientada pelo Prof. Roberto Bigonha e pelo Prof. Vladimir Iorio (UFV).
Naquela ocasião, os pesquisadores investigaram o uso de técnicas de avaliação parcial para a geração
de compiladores [8]. A ess trabalho segui-se a implementação do LinF [20], um idioma para a
especificação de fractals usando gramáticas L-System. Esses trabalhos foram feitos durante a
graduação de Fernando.
Mestrado. Durante seu mestrado, Fernando investigou ambientes de programação distribuı́dos.

Naquela ocasião, ele trabalhou na implementação de um middleware chamado Arcademis [12, 13].
Desta pesquisa resultaram várias publicações, algumas relacionadas a modelos de concorrência [19,
10, 9, 42], e outras relacionadas ao desenvolvimento de sistemas distribuı́dos em linguagens orien-
tadas a objetos [12, 43, 11, 19].
Doutorado. Durante o doutorado que Fernando lançou-se em definitivo à pesquisa em compilado-

res, em detrimento à pesquisa em sistemas orientados a objetos. Na área de compiladores, Fernando
escolheu trabalhar com Alocação de Registradores. Registradores são um tipo de memória muito
rápida, porém limitada. A decisão de quais valores alocar em registradores é fundamental para
o desempenho de programas. Naquela ocasião, Fernando iniciou um campo de pesquisa chamado
Alocação de Registradores em Grafos Cordais [14]. A partir daquele primeiro resultado, surgiram
muitos outros. Em particular, foi publicado um artigo em PLDI, a principal conferência da área de
Linguagens de Programação [16]. Naquele projeto foi mostrado que o problema de atribuição de
registro tem solução de polinomial, mesmo quando considerados registros de diferentes tamanhos.
Vários resultados importantes se seguiram, sempre publicados em conferências e periódicos que hoje
são classificados com A1 ou A2 pelo Qualis da CAPES [15, 59, 17, 18]. Alguns desses resultados
são usados na indústria de software básico até hoje [74]. Em particular, a tese de doutorado de
Fernando Pereira deu origem a uma patente (US 2009/0083721 A1). Essa patente descreve um
algoritmo exato e polinomial, muito eficiente, para alocar registradores para o processador x86.
Google. Em 2008 Fernando realizou um estágio de pesquisa na empresa Google, em um escritório

localizado na cidade de Washington DC. Fernando foi supervisionado por Daniel Berlin, e trabalhou
diretamente no projeto do compilador gcc, possivelmente a ferramenta de compilação mais utilizada
no mundo. Deste trabalho resultaram dois algoritmos de análise de ponteiros, publicados em CGO,
a principal conferência sobre geração de código [7].
5.2.2 Perı́odo 2009-2017

Durante o perı́odo que vai de Novembro de 2009 a Agosto de 2017 Fernando foi professor adjunto
do Departamento de Ciência da Computação da Universidade Federal de Minas Gerais. Nesses oito
anos, Fernando realizou pesquisa em diversas sub-áreas relacionadas a tecnologia de compilação.
Três dessas sub-áreas, contudo, merecem especial destaque, e serão discutidas com mais detalhes
no que se segue. São elas: otimização de código para placas gráficas, segurança computacional e
compilação Just-in-Time.
20
Otimização de código para placas gráficas O desenvolvimento de linguagens de programação
segue o desenvolvimento do hardware. Assim, as linguagens de programação tendem a apresentar
mais e mais abstrações para lidar com o paralelismo, porque o hardware é cada dia mais paralelo.
Hoje, o modelo de execução Single Instruction, Multiple Data (SIMD), tão conspı́cuo em unidades
de processamento gráfico (GPUs), parece ser uma alternativa acessı́vel para trazer hardware de alto
desempenho para usuários de computação. Atualmente, uma GPU tı́pica reúne algumas centenas
de processadores. No entanto, usar todo esse poder é um desafio, porque nem todas as aplicações
são tão paralelas. Além disso, os programadores têm problemas para executar aplicações regulares
até seu máximo desempenho, pois o modelo de execução da GPU ainda é muito complicado. Nesse
sentido, uma das missões de pesquisa de Fernando é afastar esse fardo dos programadores e transferi-
lo para o compilador. O grupo de pesquisa que Fernando coordena inventou o conceito de análise de
divergência [40, 37, 97, 67, 71, 36, 68, 66] e codificou a primeira implementação que está disponı́vel
hoje em um compilador de código aberto [96]. Fernando espera continuar trabalhando em técnicas
de otimização de código que visem o arquiteturas SIMD; Assim, ajudando a reduzir a lacuna entre
a complexidade das aplicações paralelas e a expressividade das linguagens de programação em que
esses problemas devem ser resolvidos.
Segurança computacional A segurança do computador tem sido sempre um problema impor-

tante na ciência da computação. E neste novo mundo onde o usuário cotidiano pode chegar às
portas de praticamente qualquer programa, esse problema é ainda mais relevante. Neste campo de
pesquisa, o objetivo é usar o compilador como uma ferramenta para rastrear vulnerabilidades em
programas. O compilador pode dar aos desenvolvedores uma visão holı́stica do código, dizendo-
lhes se as funções crı́ticas podem receber entradas de usuários mal-intencionados ou se informações
importantes podem vazar para o mundo exterior. O grupo de pesquisa de Fernando tem experimen-
tado com representações de programas não convencionais para acelerar a análise de programas. O
primeiro sucesso neste campo foi usar o formato Extended Static Single Assignment [38] para reduzir
a complexidade de resolver o problema conhecido como análise de fluxos de informação [88, 89, 90].
Essa análise está hoje disponı́vel no compilador de código aberto PHC. Fernando ainda está a bus-
car novas formas de aumentar a quantidade de programas que podem ser analisados e protegidos
automaticamente de forma eficiente. A velocidade é um problema uma vez que ele procura analisar
programas com milhões de linhas de código. Além disso, Fernando espera poder acompanhar o
fluxo de informações através do programa, mesmo quando essas informações são armazenadas na
memória. Desses esforços de pesquisa resultaram diversos trabalhos publicados em simpósios da
área de segurança computacional [84] e da área de linguagens de programação [46, 94, 53, 80, 92, 62].
Inclusive, alguns desses resultados foram publicados em OOPSLA [75], o maior congresso sobre lin-
guagens orientadas a objetos do mundo.
Compilação Just-in-Time Nos próximos anos, linguagens de programação dinâmicas, como

Python, Ruby e JavaScript, ganharão cada vez mais popularidade. Essas linguagens de pro-
gramação dão aos desenvolvedores de aplicativos um modelo de programação simples e intuitivo,
em que é fácil prototipar produtos e fazê-los funcionar rapidamente. No entanto, esta facilidade
de uso vem com um custo: é difı́cil executar programas escritos em linguagens de programação
dinâmicas de forma eficiente. Uma das esperanças de ultrapassar este obstáculo está nos compila-
dores Just-in-Time (JITs). JITs traduzem programas para código nativo enquanto esses programas
são interpretados. Fernando vem trabalhando com membros da Fundação Mozilla para tornar a
21
compilação de programas JavaScript mais eficiente e simples. Seu primeiro resultado neste campo
foi um algoritmo para eliminar testes de overflow em código binário [105, 104]. Desde então, Fer-
nando vem desenvolvendo técnicas cada vez mais poderosas para compilar programas durante a
sua interpretação, já tendo publicado resultados descrevendo tais soluções [34, 41].
Demais linhas de pesquisa Além das três linhas de pesquisa descritas acima, Fernando trabalha
em inúmeros outros projetos, sempre buscando unir aspectos teóricos e aspectos práticos da ciência
da computação. Desse esforço resultam artigos, software aberto, websites de popularização cientı́fica
e ferramentas on-line. A tı́tulo de exemplo, abaixo são listados algumas dessas outras linhas de
pesquisa, com alguns dos artigos descrevendo resultados obtidos.
• Otimizações de código sensı́veis a contexto de chamada de funções [116, 23].
• Verificações de acesso a memória em programas escritos em linguagens fracamente tipadas [98,

58, 75].
• Análise de Ponteiros [62, 80, 7, 3, 29, 82, 6].
• Mensuração de energia [24].
• Compilação para arquiteturas heterogêneas [47].
• Compilação de linguagens funcionais [91, 51, 71].
• Return Oriented Programming [73, 48, 53].
• Representações intermediárias de código [109, 107, 108].
• Análise de intervalos de variáveis inteiras [30, 46, 82, 94, 5].
• Análise de fluxo de informação [93, 100, 101, 99, 102, 92].
• Análise de sistemas distribuı́dos [49, 50, 110, 79].
5.2.3 2018 – Pós-Doutorado

Em Dezembro de 2017 Fernando começou um programa de pós-doutoramento no Centre national de
la recherche scientifique (CNRS), na unidade de Montpellier, França, sob supervisão de Abdoulaye
Gamatié. O pós-doutorado deve durar um ano. Até a presente data, Fernando, junto com seu
supervisou, publicou um artigo completo [33], e escreveu outro, ainda em submissão. A pesquisa
realizada em Montpellier deu-se principalmente sobre um fenômeno conhecido como Silent Stores.
Tal fenômeno é observado quando uma instrução de armazenamento em memória (store) escreve
um valor que já estava armazenado lá. Escritas redundantes podem ser removidas da execução do
programa, resultando em códigos mais eficientes em termos de tempo, energia e espaço.
22
10
9 Periódicos
8
Conferências
7
6
5
4
3
2
1
0
3
6
4
7
00
00
00
00
00
01
01
01
01
01
01
00
00
01
01
p2
p2
p2
p2
p2
p2
p2
p2
p2
p2
p2
p2
p2
p2
p2
Figura 10: Número de artigos indexados na biblioteca digital DBLP por ano. Produção é classifi-
cada como artigos em conferência e artigos em periódicos.
5.3 Resumo Quantitativo da Produção Intelectual

A produção intelectual de Fernando Pereira vem crescendo, e se tornando mais visı́vel, conforme
passam-se os anos. A Figura 10 mostra o número de artigos publicados, por ano, indexados na
biblioteca digital DBLP15 . Vê-se claramente que essa produção apresenta uma derivada bem posi-
tiva. E não somente aumenta o número absoluto de artigos publicados, mas também aumenta a
quantidade de artigos publicados em periódicos, e a visibilidade da produção.
Visibilidade. Com relação a este último quesito – a visibilidade da produção técnica – o número
de citações recebido por Fernando Pereira tem crescido concistentemente. A Figura 11 ilustra
essa afirmação com números. Os dados mostrados na figura foram retirados do website Google
Scholar, em Primeiro de Janeiro de 2018. Fernando terminou o ano de 2016 com 133 citações; um
salto notável, considerando-se que durante o inı́cio de sua carreira cientı́fica, ele levou seis anos
para atingir o limite de 30 citações. E, à luz do cenário da pesquisa em compiladores, descrito na
Seção 5.1, em que poucos trabalhos são citados, esse crescimento é ainda mais notável.
Qualidade. A Figura 12 classifica a produção bibliográfica de Fernando Pereira de acordo com o

Qualis CAPES 2012-2016. Para a classificação de conferências, usou-se o relatório Qualis de 2017,
referente ao perı́odo mencionado. São classificados somente os artigos enumerados na biblioteca
digital DBLP. Conforme a figura mostra, Fernando possui 11 artigos publicados em revistas classifi-
cados no chamado extrato superior, que abarca as classificações A1, A2 e B1. Esse número aumenta
consideravelmente quando consideramos os artigos publicados em conferências: Fernando possui 9
artigos em veı́culos A1, 18 em A2 e 1 em B1; ou seja, 28 trabalhos publicados em conferências são
classificados como pertencentes ao extrato superior. Vale ressaltar que a área de Linguagens de
15
Disponı́vel em http://dblp.uni-trier.de/pers/hd/p/Pereira:Fernando_Magno_Quint=atilde=o
23
180
160
140
120
100
80
60
40
20
0
3
7
00
00
00
00
00
00
00
01
01
01
01
01
01
01
01
p2
p2
p2
p2
p2
p2
p2
p2
p2
p2
p2
p2
p2
p2
p2
Figura 11: Citações por ano, conforme apreendido pelo Google Scholar.
Períodicos Conferências
A1
A1
B1 B3
B2
18
8 A2
A2
B1
Figura 12: Qualis dos veı́culos contados na Figura 10. Para a classificação das conferências, usou-
se o Qualis CAPES de 2016-2012.
Programação possui somente quatro conferências classificadas como A1: PLDI, PPoPP, OOPSLA
e POPL, e Fernando já publicou seus trabalhos – como primeiro ou último autor – em todas eleas,
exceto POPL. Além disso, quase todos os artigos publicados por Fernando nos últimos oito anos
foram como último autor, o que ressalta seu papel de orientador e coordenador de pesquisa.
24
6 Bolsas, Projetos e Orientações
Esta seção trata das bolsas já recebidas pelo docente, e dos projetos que ele coordenou durante o
perı́odo que vai de 2009, ano de sua contratação, até 2017.
6.1 Bolsas
A Tabela 1 descreve as bolsas já recebidas pelo docente que estão relacionadas a atividades de
pesquisa. Essas bolsas foram custeadas por instituições públicas de fomente a pesquisa.
Projeto Agência: Edital Perı́odo Valor

PQ CNPq: Produtividade em Pesquisa 01/03/2013 - 28/02/2016 R$ 39.600,00
PPM FAPEMIG: Programa Pesquisador Mineiro 01/07/2014 - 30/06/2016 R$ 48.000,00
PQ CNPq: Produtividade em Pesquisa 01/03/2016 - 28/02/2018 R$ 39.600,00
PPM FAPEMIG: Programa Pesquisador Mineiro 01/07/2016 - 30/06/2018 R$ 48.000,00
Tabela 1: Bolsas custeadas por instituições de fomento a pesquisa recebidas pelo docente.
A Tabela 2 descreve as bolsas já recebidas pelo docente que estão relacionadas a atividades de
pesquisa, custeadas por instituições privadas. Ambas as bolsas descritas na tabela estão relaciona-
das a projetos de pesquisa que o docente coordenou.
Empresa: Projeto Perı́odo Valor

MaxTrack: teste de software embarcado 01/03/2015 - 28/02/2016 R$ 43.200,00
LG Electronics: Paralelização Automática 01/03/2015 - 31/01/2018 R$ 52.800,00
Tabela 2: Bolsas custeadas por empresas privadas, recebidas pelo docente enquanto coordenador
de projeto de pesquisa.
6.2 Participação em Grupos de Pesquisa

O docente participa de cinco grupos de pesquisa cadastrados no Diretório de Grupos de Pesquisa
do CNPq, a saber:
• Compiladores. Grupo coordenado pelo próprio docente e pelo Prof. Renato Antônio Celso
Ferreira.
• Grupo de Segurança Digital, Criptografia e Privacidade. Coordenador: Prof. Leonardo
Barbosa.
• Linguagens e Ambientes de Programação. Coordenadores: Prof. Roberto Bigonha e Profa.
Mariza Bigonha.
• Escalabilidade e Eficiência em Sistemas de Computação. Coordenador: Prof. Wagner Meira
Jr.
• Computação de Alto Desempenho. Coordenador: Edson Borin.
25
6.3 Projetos de Pesquisa
O candidato é, atualmente, o coordenador de quatro projetos de pesquisa16 . Um desses projetos
envolve recursos provenientes de empresa privada: a LG Electronics. Dois dos projetos já termina-
dos também se deram com empresas privadas: a Intel e a Maxtrack. A existência desses recursos,
provenientes da indústria de informática, demonstram que a pesquisa realizada pelo candidato en-
contra aplicação prática. Seis dos alunos de mestrado que já trabalharam com o candidato, um de
seus alunos de doutorado, e seis de seus alunos de iniciação cientı́fica já recebem bolsas mantidas
por tais recursos. Os demais estudantes que trabalham com ele são mantidos por bolsas vindas de
agências públicas, como o CNPq, a CAPES e a FAPEMIG. A relação dos projetos vigentes que
o candidato coordena pode ser vista logo abaixo. Além desses projetos, o candidato participa de
mais três projetos ainda vigentes: FAPEMIG- PROEX, InWeb e um edital universal CNPq, do
prof. Leonardo Barbosa.
• Tı́tulo: Automatização de Testes de Software em Sistemas Embarcados

Agência financiadora: CNPq – Edital Universal
Orçamento: R$ 30.010,00
Previsão de Término: 31/03/2018
• Tı́tulo: Paralelização Automática de Código para Aparelhos Móveis

Agência financiadora: LG Electronics (Capital Privado)
Término: 31/01/2018
• Tı́tulo: PROSPieL – Profiling and specialization for locality

Agência financiadora: FAPEMIG – Cooperação FAPEMIG/INRIA
• Tı́tulo: Usando o compilador para aumentar a eficiência e a segurança de programas

Agência financiadora: FAPEMIG (Programa Pesquisador Mineiro)
A relação de projetos que o proponente coordenou é listada abaixo em ordem cronológica de

término.
• Tı́tulo: Alocação de Registradores agrupados em Classes

Agência financiadora: UFMG (Recém Contratado)
Término: 01/12/10.
• Tı́tulo: Análise e Otimização de Aplicações em CUDA

Agência financiadora: FAPEMIG (Edital Universal)
Término: 02/11/2011.
16
Além desses projetos, o proponente coordena, ou já coordenou, seis projetos de extensão.
26
• Tı́tulo: Compiler Support for Emerging Parallel Architectures
Agência financiadora: UFMG (Edital Cátedras Francesas na UFMG)
Término: 31/11/2014
• Tı́tulo: Rastreamento de Informação em Estruturas de Dados

Agência financiadora: FAPEMIG (Edital Universal)
Término: 13/02/15.
• Tı́tulo: eCoSoC – Energy-aware Code Optimization for System on a Chip Devices

Agência financiadora: Intel (Capital Privado)
Orçamento: 210.000,00 dólares (aproximadamente R$ 670.000,00)
Término: 28/02/2015.
Observação: este projeto foi có-coordenado com o Prof. Leonardo Barbosa.
• Tı́tulo: A language runtime with fault-resiliency for approximate computing

Agência financiadora: UFMG (Edital Cátedras Francesas na UFMG)
Término: 31/11/2015
• Tı́tulo: Teste Automático de Código Embarcado

Agência financiadora: Maxtrack (Capital Privado)
Término: 12/02/16
• Tı́tulo: Usando o compilador para aumentar a eficiência

e a segurança de programas
Agência financiadora: FAPEMIG (Programa Pesquisador Mineiro)
Além desses projetos, Fernando Pereira coordenou cinco bolsistas Probic/PIBIC. Cada um
desses alunos recebeu uma bolsa padrão de iniciação cientı́fica, no valor de R$ 400.00. No total,
Fernando trouxe para o DCC-UFMG o valor de R$ 24.000,00 relativos a esses projetos de iniciação
cientı́fica. Assim, somados, os projetos que o docente já coordenou ou coordena somam mais
de um milhão de reais. Além desses projetos, o docente também já participou ou participa de
vários projetos coordenados por outros pesquisadores. Esses projetos estão descritos em seu Lattes.
Dentre eles, citam-se:
• Um Algoritmo de Fusão para Registradores Compartilhados. Coordenado pela profa. Mariza

Bigonha. Edital de Cooperação FAPEMIG-INRIA, 2011.
• INCT para a Web. Instituto Nacional de Ciência e Tecnologia para a Web. Coordenado pelo
prof. Virgı́lio Almeida. Edital INCTs, CNPq e FAPEMIG, 2009.
• MASWeb. Modelos, Algoritmos e Sistemas para a Web. Coordenado pelo prof. Nı́vio Ziviani.
Edital PRONEX FAPEMIG, projeto número APQ 01400-14, 2015.
27
6.4 Orientações
Durante a sua carreira como Professor Adjunto do DCC-UFMG, Fernando Pereira concluiu a
orientação de diversos alunos de mestrado e iniciação cientı́fica, além da orientação de um aluno de
doutorado, e a có-orientação de um aluno de doutorado. Vários desses alunos ganharam prêmios
reconhecendo sua excelência cientı́fica. Esses prêmios são descritos na Seção 6.4.4.
6.4.1 Orientações de Doutorado

Abaixo vê-se a relação de estudantes de doutorado que defenderam suas teses sob a orientação, ou
a có-orientação, do docente, com a relação de artigos que publicaram juntos:
1. Bruno Rodrigues Silva. Análise Esparsa de Fluxo de Informação. 2016. (Orientação) [92,
102, 99, 101, 100]
2. Bruno Rocha Coutinho. Utilização de técnicas de análise estática e dinâmica para oti-
mização de aplicações de propósito geral em GPUs. 2011. (Có-Orientação. Orientador
Principal: Wagner Meira Jr.) [37, 35, 36]
Abaixo segue a relação dos alunos de doutorado do Programa de Pós-Graduação em Ciência da

Computação que o docente atualmente orienta:
• Andrei Rimsa Alves

Ano de Ingresso: 2015
Tı́tulo Previsto da Tese: Descoberta de Paralelismo Latente via Profiling.
• Mateus Tymburibá
Tı́tulo Previsto da Tese: Uso de Predição de Branches para Descobrir Ataques de Pro-
gramação Orientada a Retorno
• Leandro Terra Cunha Melo

Tı́tulo Previsto da Tese: Compilação de Código C Parcialmente Disponı́vel.
6.4.2 Orientações de Mestrado

Abaixo vê-se a relação de estudantes de mestrado que defenderam suas teses sob a orientação, ou
có-orientação, do docente, com a relação de artigos que publicaram juntos:
1. Marcelo Pereira Novaes. Unassisted Mapping of Computations on big.LITTLE Architec-

tures via Reinforcement Learning. 2018.
2. Marcus Rodrigues de Araújo [65, 87]. Compilação de Código Parcialmente Disponı́vel.

2018.
3. Péricles Rafael Oliveira Alves [66, 5, 41, 67, 3, 34, 4, 114, 28]. Enabling Code Optimiza-
tions Throught Hybrid Analysis of Memory Access Ranges. 2017.
28
4. Rubens Emı́lio Alves Moreira [53, 72, 73, 48, 71]. Ré-Vetorização de Chamadas de
Função. 2017.
5. Vitor Mendes Paisante [79, 62, 80, 49]. Symbolic Range Analysis of Pointers. 2016.
6. Victor Hugo Sperle Campos [29, 94, 30, 114, 28]. Restrictification of Function Arguments.
2016.
7. Kézia Corrêa Andrade Moreira [70, 45]. Anotação Automática de Código com Diretivas
OpenACC. 2016.
8. Henrique Nazaré [29, 82, 75, 34, 98, 41]. Symbolic Range Analysis. 2016.
9. Francisco Demontiê dos Santos Junior [32, 31]. Geração de Casos de Testes para Lin-
guagens com Aritmética de Ponteiros. 2016. (có-orientação. Orientadora: Profa. Mariza
Bigonha)
10. Douglas do Couto Teixeira [47, 46, 45]. Optimizations for Graphics Processing Units.
2015.
11. Bruno Morais Ferreira [51]. The Dinamica Virtual Machine For Geosciences. 2015.
12. Raphael Ernani Rodrigues [5, 82, 94, 30, 93]. Scalable and Precise Range Analysis on the
Interval Lattice. 2014.
13. Matheus Silva Vilela [23, 116]. Context-Aware Code Optimizations Based on Function
Cloning. 2014.
14. Teo Milanez Brandão [68, 69]. Thread Synchronization in SIMD Hardware. 2013. (có-
orientação. Orientador: Prof. Renato Ferreira)
15. Igor Rafael de Assis Costa [34, 4, 41]. Parameter-Based Speculative Value Specialization.
2013.
16. Diogo Nunes Sampaio [96, 36, 97, 35, 37]. Divergence Analysis with Affine Constraints.
2013.
17. André Luiz Camargos Tavares [108, 107, 109]. Alocação de Registradores Desacoplada
Baseada em Coloração de Grafos com Compartilhamento Hierárquico. 2011. (có-orientação.
Orientador: Prof. Roberto Bigonha)
18. Gabriel Quadros Silva [84]. Tracking Indirect Information Flow in Languages with Des-
tructive Update. 2011. (có-orientação. Orientadora: Profa. Mariza Bigonha)
19. Marcos Rodrigo Sol Souza [104, 105]. Eliminação de Testes de Overflow para Compila-
dores de Trilhas. 2011. (có-orientação. Orientadora: Profa. Mariza Bigonha)
20. Andrei Rimsa Álvares [89, 88, 90]. Algoritmo Eficiente de Análise Estática para Procurar
Ataques do Tipo Variáveis Contaminadas. 2010. (có-orientação. Orientador: Prof. Roberto
Bigonha)
29
21. Leonardo Luiz Padovani da Mata [40, 39]. Geração Automática de Código para Execução
em um Ambiente de Computação Dataflow. 2010. (có-orientação. Orientador: Prof. Renato
Ferreira)
Abaixo segue a relação dos alunos de mestrado do Programa de Pós-Graduação em Ciência da

Computação que o docente atualmente orienta. Ressalta-se que todos esses alunos possuem bolsas,
custeadas por instituições públicas, ou por empresas privadas:
• Caio Araújo N. de Lima
• Gabriel Poesia
• Marcelo Novaes
• Marcos Yukio Siraichi
• Marcus Rodrigues
• Pedro Ramos
6.4.3 Orientações de Iniciação Cientı́fica

Ao long de sua carreira, o docente já orientou diversos alunos em projetos de iniciação cientı́fica. Se-
gue, abaixo, a lista de alunos que o candidato Orientou Diretamente. Além desses alunos, Fernando
Pereira có-orientou diversos outros, que não serão citados neste documento.
1. Pedro Henrique Ramos Costa. Mineração de Tarefas em Código Irregular, 2016.
2. Marcos Rodrigues de Araújo. Compilação de Código C Parcialmente Disponı́vel, 2015.
3. Simon Moll. Hoisting of Array Bounds Checks, 2014.
4. Junio Cezar Ribeiro da Silva. Automatic Inference of Asymptotic Complexity, 2014.
5. Péricles Rafael Alves. Dynamic Pointer Disambiguation, 2014.
6. Rafael Martins de Sousa. Dynamic Trip Count Prediction, 2013.
7. Guilherme Mendes Marques de Oliveira. Runtime Value Specialization, 2013.
8. Alberto de Sá Cavalcanti. Compilação de PTX para SASS, 2012.
9. Henrique Nazaré Santos. Runtime Value Specialization, 2012
10. Victor Hugo Sperlle Campos. Interprocedural Non-Iterative Range Analysis, 2011.
11. Douglas Do Couto Teixeira. The Design and Implementation of a non-iterative Range
Analysis Algorithm on a Production Compiler, 2010.
12. Fernando Carvalho Coelho. Development of a Testing Framework for the Ocelot CUDA
Compiler, 2010.
30
Abaixo segue a relação dos alunos de iniciação cientı́fica que o docente atualmente orienta.
Todos esses alunos possuem bolsas, custeadas por instituições públicas, ou por empresas privadas:
• Gleison Souza Diniz Mendonça (financiado por bolsa da LG)
• Junio Cezar (financiado por bolsa CNPq – Edital Universal)
• Breno Campos Ferreira Guimarães (financiado por bolsa da LG)
• Tarsila Bessa (financiada por bolsa da LG)
• Carina Capelão (financiada por bolsa da Prodemge)
6.4.4 Prêmios Obtidos por Estudantes

Vários dos alunos orientados por Fernando receberam prêmios pelos trabalhos que desenvolveram.
Esses prêmios incluem resultados obtidos em competições estudantis, e tı́tulos de melhor trabalho
apresentado em conferência. Abaixo citam-se os prêmios recebidos por estudantes:
• 2016: Primeiro lugar na competição estudantil da ACM, com o artigo “Inference of Peak
Density of Indirect Branches to Detect ROP Attacks” [53], apresentado pelo aluno Rubens
Emı́lio Alves Moreira.
• 2015: Melhor artigo do XIX Simpósio Brasileiro de Linguagens de Programação: “Restriti-

ficação” [114], publicado com os alunos Campos Victor e Alves Péricles.
• 2015: Terceiro melhor artigo do XIX Simpósio Brasileiro de Linguagens de Programação:

“Automatic Inference of Loop Complexity through Polynomial Interpolation” [31], publicado
com os alunos Junio Cezar e Francisco Demontiê.
• 2015: Melhor Ferramenta do Congresso Brasileiro de Software, Teoria e Prática (CBSoft):

“Restrictifier: a tool to disambiguate pointers at function call sites” [28], publicado com os
alunos Campos Victor e Alves Péricles.
• 2015: Segunda Melhor Ferramenta do Congresso Brasileiro de Software, Teoria e Prática (CB-
Soft): “FlowTracker - Detecção de Código Não Isócrono via Análise Estática de Fluxo” [102],
publicado com o aluno Bruno Rodrigues.
• 2015: Segundo melhor artigo no XV Simpósio Brasileiro de Segurança da Informação e de Sis-

temas Computacionais: “Uma Técnica de Análise Estática para Detecção de Canais Laterais
Baseados em Tempo” [99], publicado com o aluno Bruno Rodrigues.
• 2014: Segunda Melhor Dissertação de Mestrado: “Divergence Analysis with Affine Cons-
traints”. Prêmio conferido pela Sociedade Brasileira de Computação. Trabalho realizado
pelo aluno Diogo Sampaio.
• 2013: Menção Honrosa no XIII Simpósio Brasileiro de Segurança da Informação (SBSeg)

pelo artigo “Uma Representação Intermediária para a Detecção de Vazamentos Implı́citos de
Informação” [100], publicado com o aluno Bruno Rodrigues.
31
• 2012: Melhor artigo do Simpósio Brasileiro de Linguagens de Programação 2012 “Spill Code
Placement for SIMD Machines” [97], publicado com os alunos Diogo Sampaio e Rafael
Martins.
• 2012: Melhor trabalho Ciências Exatas e da Terra “Especialização de valores em compilado-

res Just-in-Time”do aluno Péricles Rafael, na Semana de Iniciação Cientı́fica da UFMG,
Universidade Federal de Minas Gerais.
• 2010: Melhor artigo no XIV Simpósio Brasileiro de Linguagens de Programação: “Removing

Overflow Tests via Run-Time Partial Evaluation” [104], publicado com o aluno Marcos
Rodrigo Sol.
• 2010: Segundo melhor artigo no XIV Simpósio Brasileiro de Linguagens de Programação:

“Efficient SSI Conversion” [108], publicado com o aluno André Tavares.
• 2010: Terceiro melhor artigo no XIV Simpósio Brasileiro de Linguagens de Programação:

“Efficient Static Checker for Tainted Variable Attacks” [88], publicado com o aluno Andrei
Alves Rimsa.
• 2010: Melhor artigo do 22nd International Symposium on Computer Architecture and High
Performance Computing (SBAC-PAD): “Performance Debugging of GPGPU Applications
with the Divergence Map” [37], publicado com os alunos Bruno Rocha Coutinho e Diogo
Nunes Sampaio.
6.4.5 Empregos Obtidos por Ex-Alunos

Vários dos ex-alunos de pós-graduação orientados por Fernando Pereira ocupam hoje posição de
destaque na indústria de software nacional e estrangeira. Algumas dessas posições são relacionadas
na lista abaixo:
• Bruno Moraes Ferreira (Mestrado) – Google
• Bruno Rodrigues Silva (Doutorado) – CEFET-MG
• Diogo Nunes Sampaio (Mestrado) – INRIA
• Douglas do Couto Teixeira (Mestrado) – Assembléia Administrativa, MG
• Francisco Demontie dos Santos Junior (Mestrado) – Amazon
• Henrique Nazare Santos (Mestrado) – Google
• Marcos Rodrigo Sol (Mestrado) – Raro Labs
• Pericles Rafael (Mestrado) – Microsoft
• Raphael Ernani Rodrigues (Mestrado) – Microsoft
• Rubens Emı́lio (Mestrado) – Microsoft
• Victor Hugo Sperle Campos (Mestrado) – Cadence
7 Demais atividades
Atendendo ao item 6.6.1.(f-g) da Chamada CNPq 09/2018, esta seção descreve outras atividades
executadas pelo proponente desta proposta. Serão descritas atividades desenvolvidas pelo pesqui-
sador desde que ele foi contratado pelo Departamento de Computação da Universidade Federal de
Minas Gerais em Novembro de 2009.
32
7.1 Orientações extra-curriculares concluı́das
O docente orientou 21 Projetos Orientados em Computação (POC) entre os anos de 2009 e 2017.
POCs são requisito necessário para a formação no Bacharelado em Ciência da Computação. Ele
também orientou quatro Monografias do curso de Sistemas de Informação neste mesmo perı́odo. A
relação de monografias orientadas pode ser encontrada no currı́culo lattes do docente.
7.2 Bancas de teses e dissertações externas à UFMG

O docente participou de diversas bancas de trabalhos de conclusão. A relação completa desses
trabalhos está descrita em seu currı́culo Lattes. Abaixo, ressaltam-se os números:
• 4 bancas de Monografia do Curso de Especialização em Engenharia de Software oferecido pelo

DCC-UFMG.
• 17 bancas de mestrado – seis delas fora da UFMG.
• 10 defesas finais de doutorado – seis delas fora da UFMG.
• 4 qualificações de doutorado – três delas fora da UFMG.
7.3 Bancas de Concursos

O docente participou como membro de banca nos seguintes concursos para provimento de vagas
docentes em instituições públicas de ensino superior:
• Universidade: Universidade do Estado do Amazonas

Banca: J. Stolfi, A. Castro e Fernando Pereira.
Ano: 2013
• Universidade: Universidade Federal de Ouro Preto

Banca: Vasconcellos, C. D.; Cardoso, E. M. e Fernando Pereira
Ano: 2012
• Universidade: Universidade Federal de Ouro Preto

Banca: Reis, L.; Iorio, V. e Fernando Pereira
Ano: 2011
• Universidade: Universidade Federal de Itajubá

Banca: Silveira, C.; e Fernando Pereira
Ano: 2011
• Universidade: Universidade Federal de Uberlândia

Banca: Maia, M.; Braga, C.; e Fernando Pereira
Ano: 2010
33
7.4 Outras atividades sem remuneração adicional especı́fica
Cursos de curta duração fora da UFMG. O docente vem ministrando vários cursos em
universidades estrangeiras. Abaixo seguem listados os cursos ministrados pelo docente entre 2009
e 2017:
• Curso: Code Generation Techniques for Graphics Processing Units.

Evento: International Symposium on Code Generation and Optimization (CGO)
Local: Shengzhen, China
Duração: 3 horas
Ano: 2013.
• Curso: Code Optimization with the LLVM Compiler.

Evento: Projeto eCoSoC – Workshop anual
Local: Intel, Hillsboro, OR, Estados Unidos
Ano: 2014
• Curso: Static Analysis and Optimization with LLVM

Evento: Congresso Brasileiro de Software – Teoria e Prática (CBSoft)
Local: Maceió, AL, Brasil
Ano: 2014
• Curso: Static Analysis and Optimizations

Evento: Compilation et Analyse de Programmes (CAP), M1, ENS Lyon
Local: Lyon, França
Ano: 2015
• Curso: Programación Modular y Anti-Patrones de Proyecto

Evento: Actualización Profesional – Calidad de Software
Local: San Luis, Argentina
Ano: 2010
• Curso: Code Optimization Techniques for Graphics Processing Units

Evento: Escola de Verão do LNCC – Computação de Alto Desempenho
Local: LNCC, Petrópolis, RJ
Duração: seis horas
Ano: 2011/2012
• Curso: Introduction to Compilers

Evento: Thirteenth International Summer School on Advanced Computer Architecture and
Compilation for High-Performance and Embedded Systems. (Vide Figura 13)
Local: Fiuggi, Itália
Duração: oito horas
Ano: 2017
34
Figura 13: Em Julho de 2017 Fernando Pereira ministrou a cadeira “Compiladores”em ACACES.
Esta escola de verão acontece anualmente, e envolve a participação de cerca de 250 estudantes de
universidades de todo o mundo. Entre os instrutores deste ano, havia pesquisadores de renome,
como Colin Adams, Rosa Badia, Koen Bertels, e Gernot Heiser. Maiores informações estão dis-
ponı́veis na página do evento.
Revisão de Artigos Submetidos a Periódicos. O docente tem participado ativamente da

revisão de artigos submetidos a periódicos. Dentre os periódicos para os quais ele já revisou artigos
citam-se:
• ACM Transactions on Programming Languages and Systems;
• ACM Transactions on Architecture and Code Optimization;
• IEEE Transactions on Computers;
• ACM Transactions on Embedded Computing Systems;
• Computer Languages, Systems & Structures;
• ACM Transactions on Architecture and Code Optimization.
Participação em Comitês de Programa. Conferências são a principal forma de divulgação de

material cientı́fico em ciência da computação. As conferências de ciência da computação possuem
comitês de programas: grupos de pessoas que escolhem os artigos que serão apresentados naquele
simpósio. Fernando já serviu em vários comitês de programa, dos quais destacam-se:
• Simpósio Brasileiro de Linguagens de Programação (SBLP) – 2010-2017;
35
• Sessão de Ferramentas do CBSoft (CBSoft Tools) – 2014-2017;
• Workshops de Dissertações e Teses (WTDSoft) – 2014-2017;
• Simpósio Brasileiro de Segurança Computacional;
• Onward! Essays;
• Simpósio de Sistemas Computacionais de Alto Desempenho (WSCAD)
• The International Symposium on Compiler Construction – duas ocasiões.
7.5 Inserção Internacional

A inserção de Fernando Pereira em cı́rculos de pesquisa estrangeiros vem aumentando constante-
mente. Tal inserção dá-se por meio de cooperações cientı́ficas, visitas técnicas, acolhida de pesqui-
sadores estrangeiros e publicações de artigos com pesquisadores estrangeiros. Abaixo descrevem-se
alguns desses itens.
Projetos de Cooperação Cientı́fica com Instituições estrangeiras. Fernando Pereira já

participou, como coordenador de pelo menos quatro projetos financiados por instituições estran-
geiras, ou có-financiados por elas. A lista de tais projetos segue abaixo:
• eCoSoC – Energy-aware Code Optimization for System on a Chip Devices.
Instituição financiadora: Intel.
Paı́s de origem do financiamento estrangeiro: Estados Unidos.
• Compiler Support for Emerging Parallel Architectures.
Instituição financiadora: UFMG & Consulado da França no Brasil.
Paı́s de origem do financiamento estrangeiro: França.
• A language runtime with fault-resiliency for approximate computing
Instituição financiadora: UFMG & Consulado da França no Brasil.
• PROSPieL – Profiling and specialization for locality
Instituição financiadora: FAPEMIG & INRIA
Visitas Técnicas em Universidades Estrangeiras. Fernando Pereira tem desenvolvido coo-

peração cientı́fica com pesquisadores estrangeiros. Dentre tais atividades destacam-se:
• Visita técnica à University of California, Los Angeles, em 2014;
• Duas visitas técnicas à Intel Hillsboro em 2013 e 2014;
• Visita técnica à Korea University e LG Headquarters in 2015;
• Estágio de cinco semanas em INRIA Grenoble em 2014;
• Estágio de quatro semanas em ENS Lyon em 2015;
• Estágio de quatro semanas em ENS Lyon e INRIA Rennes em 2017.
• Pós-doutorado de um ano no CNRS – Unidade Montpellier, em 2018.
Acolhida de Pesquisadores Estrangeiros. Fernando Pereira recebeu pelo menos três pesqui-
sadores durante três ou mais meses, no laboratório que coordena:
• Sylvain Collange - INRIA Rennes: pós-doutorado de nove meses (2010) e duas visitas de três
meses (2014 e 2015);
• Simon Möll - Saarland U: estágio de três meses
36
Guido Araújo
Edson Borin
Diego Aranha
Jie Liu
Márcio Pereira
Jens Palsberg
Marcelo D'Amorim
Hao Chi Wong
Unicamp
José Nacif Microsoft
UCLA
UFPE Quentin Colombet
Intel
Krishna Nandivada UFV
Apple Jonathan Lee
IIT Madras
Johannes Doerfert
Google
Daniel Berlin
Saarland U
Fernando
Sebastian Hack
Pereira
CNRS
Abdoulaye Gamatié
Michael Frank LGE STM
Christophe Guillon
Fabrício Ferracioli ENS Lyon

ETH
Maroua Maalej
U Rennes
Tobias Grosser
INRIA
Laure Gonnord
Christiane Pousa
Elie Gedeon
Benoit Boissinot
Fabrice Rastello
Sylvain Collange
Alexandros Lamprineas
Fabian Gruber
Figura 14: Lista de có-autores de Fernando Pereira que trabalham em instituições diferentes da
UFMG. Có-autores foram retirados da biblioteca DBLP. Foram citados somente pesquisadores
profissionais; alunos em formação não foram listados.
• Solène Mirliaz - Université de Rennes 1: estágio de três meses
Publicações com Pesquisadores de Instituições Estrangeiras. Fernando vem publicando

vários artigos com pesquisadores estrangeiros. A Figura 14 sumariza essas cooperações.
37
8 Conclusão
Esta proposta apresentou o projeto de pesquisa proposto por Fernando Magno Quintão Pereira
como requisito essencial para submissão ao Edital CNPq 09/2018 – Bolsa de Produtividade em
Pesquisa. O objetivo do projeto é utilizar o compilador para aumentar a eficiência energética de
programas. Trata-se de um projeto na área de compiladores. A pesquisa em compiladores é ainda
incipiente no Brasil. Embora existam no paı́s núcleos de excelência na área, como o Laboratório de
Sistemas Computacionais da UNICAMP, há ainda muito o que pode ser conseguido nesse campo.
Ressalta-se que a pesquisa em compiladores é importante, pois esse tipo de software é um dos
pilares fundamentais da ciência da computação. Grandes conquistas como os sistemas operacionais
modernos, os smartphones, e a própria Internet, somente foram possı́vel porque cientistas como
John Backus, Nicklaus Wirth, Grace Hopper e John McKarthy dedicaram imenso esforço para a
construção e evolução de compiladores. E mesmo que grande avanço tenha sido conseguido nesta
área, há ainda muito o quê conseguir. A pesquisa proposta representa mais um passo em tal direção.
Referências
[1] Alfred V. Aho, Monica S. Lam, Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles,
Techniques, and Tools (2nd Edition). Addison Wesley, Boston, MA, US, 2006.
[2] F. E. Allen. The history of language processor technology in ibm. IBM J. Res. Dev.,
25(5):535–548, 1981.
[3] Pericles Rafael Alves, Fabian Gruber, Johannes Doerfert, Alexandros Labrineas, Tobias Gros-
ser, Fabrice Rastello, and Fernando Magno Quint ao Pereira. Runtime pointer disambigua-
tion. In OOPSLA, pages 589–606. ACM, 2015.
[4] Pericles Rafael Oliveira Alves, Igor Rafael de Assis Costa, Fernando Magno Quint ao Pereira,
and Eduardo Lage Figueiredo. Parameter based constant propagation. In SBLP, pages 57–71.
Springer, 2012.
[5] Péricles Rafael Oliveira Alves, Raphael Ernani Rodrigues, Rafael Martins de Souza, and
Fernando Magno Quint ao Pereira. A case for a fast trip count predictor. Information
Processing Letters, 115(2):146–150, 2015.
[6] Neto Antonio, Melo Leandro, Neto Omar, Fernando Pereira, and Barbosa Leonardo. Pro-
tecting programs against memory violation in hardware. Revista IEEE America Latina,
13(3):885–891, 2015.
[7] Fernando Magno Quint ao Pereira and Daniel Berlin. Wave propagation and deep propagation
for pointer analysis. In CGO, pages 126–135. ACM, 2009.
[8] Fernando Magno Quint ao Pereira, Roberto da Silva Bigonha, Mariza Andrade da Silva Bi-
gonha, and Vladimir Oliveira de Iorio. Avaliação parcial de programas usando cmix/ii. In
SBLP, pages C32–C47. SBC, 2001.
[9] Fernando Magno Quint ao Pereira, Marco Túlio de Oliveira Valente, Roberto da Silva Bi-
gonha, and Mariza Andrade da Silva Bigonha. A java-based simulator for ad hoc mobile
distributed systems. In FIDJI, page Springer. 1-15, 2002.
38
[10] Fernando Magno Quint ao Pereira, Marco Túlio de Oliveira Valente, Roberto da Silva Bigo-
nha, and Mariza Andrade da Silva Bigonha. Uma linguagem para coordenação de aplicações
em redes móveis ad-hoc. In SBLP, pages 152–165. SBC, 2002.
gonha, and Mariza Andrade da Silva Bigonha. Chamada remota de métodos na plataforma
j2me/cldc. In WCSF, pages 157–168. SBC, 2003.
gonha, and Mariza Andrade da Silva Bigonha. Chamada remota de métodos na plataforma
j2me/cldc. Revista do Instituto Nacional de Telecomunicações, 7(1):21–31, 2004.
gonha, and Mariza Andrade da Silva Bigonha. Arcademis: a framework for object oriented
communication middleware development. Software: Practice and Experience, 36(5):495–512,
2006.
[14] Fernando Magno Quint ao Pereira and Jens Palsberg. Register allocation via coloring of
chordal graphs. In APLAS, pages 315–329. Spring, 2005.
[15] Fernando Magno Quint ao Pereira and Jens Palsberg. Register allocation after classical ssa
elimination is np-complete. In FOSSACS, pages 79–93. Springer, 2006.
[16] Fernando Magno Quint ao Pereira and Jens Palsberg. Register allocation by puzzle solving
extended. In PLDI, pages 216–226. ACM, 2008.
[17] Fernando Magno Quint ao Pereira and Jens Palsberg. Ssa elimination after register allocation.
In CC, pages 158 – 173. Springer, 2009.
[18] Fernando Magno Quint ao Pereira and Jens Palsberg. Punctual coalescing. In CC, pages
165–184. Springer, 2010.
[19] Fernando Magno Quint ao Pereira, Wagner Salazar Pires, Marco Túlio de Oliveira Valente,
Roberto da Silva Bigonha, and Mariza Andrade da Silva Bigonha. Tactics for remote method
invocation. Journal of Universal Computer Science, 10(7):824–842, 2004.
[20] Fernando Magno Quint ao Pereira, Leonardo Trivelato Rolla, Cristiano Gato de Rezende, and
Rodrigo Lima Carceroni. The language linf for fractal specification. In SIBGRAPI, pages
67–74. IEEE, 2003.
[21] Andrew W. Appel and Jens Palsberg. Modern Compiler Implementation in Java. Cambridge
University Press, Cambridge, UK, 2nd edition, 2002.
[22] John Backus. The history of fortran i, ii, and iii. SIGPLAN Not., 13(8):165–180, 1978.
[23] Guilherme Balena, Matheus Vilela, and Fernando Pereira. Resolução de bugs de desempenho
via clonagem de funções. In SBLP, pages 1–20. SBC, 2013.
[24] Tarsila Bessa, Pedro Quint ao, Michael Frank, and Fernando Magno Quint ao Pereira. Jet-
sonleap: A framework to measure energy-aware code optimizations in embedded and hetero-
geneous systems. In SBLP, pages 16–30. SBC, 2016.
39
[25] Tarsila Bessa, Christopher Gull, Pedro Quintao, Michael Frank, Jose Nacif, and Fernando
Magno Quintao Pereira. JetsonLEAP: a framework to measure power on a heterogeneous
system-on-a-chip device. Science of Computer Programming, pages –, 2017.
[26] Christian Bienia, Sanjeev Kumar, Jaswinder Pal Singh, and Kai Li. The PARSEC benchmark
suite: Characterization and architectural implications. In PACT, pages 72–81. ACM, 2008.
[27] Rainer Buchty, Vincent Heuveline, Wolfgang Karl, and Jan-Philipp Weiss. A survey on
hardware-aware and heterogeneous computing on multicore processors and accelerators. Con-
currency and Computation: Practice and Experience, 24(7):663–675, 2012.
[28] Victor Campos, Pericles Alves, and Fernando Pereira. Restrictifier: a tool to disambiguate
pointers at function call sites. In CBSoft Tools, pages 89–96. SBC, 2015.
[29] Victor Hugo Sperle Campos, Péricles Rafael Alves, Henrique Nazaré, and Fernando
Magno Quint ao Pereira. Restrictification of function arguments. In CC, pages 163–173.
ACM, 2016.
[30] Victor Hugo Sperle Campos, Raphael Ernani Rodrigues, Igor Rafael de Assis Costa, and
Fernando Magno Quint ao Pereira. Speed and precision in range analysis. In SBLP, pages
42–56. Springer, 2012.
[31] Francisco Demontie Junio Cezar, Mariza Bigonha, Frederico Campos, and Fernando Pereira.
Automatic inference of loop complexity through polynomial interpolation. In SBLP, pages
1–15. Springer, 2015.
[32] Junio Cezar, Francisco Demontie, Mariza Bigonha, and Fernando Pereira. Asymptus - a tool
for automatic inference of loop complexity. In CBSoft Tools, pages 97–104. SBC, 2015.
[33] Junio Cezar, Michael Frank, Abdoulaye Gamatie, and Fernando Pereira. A compiler-centric
infra-structure for whole-board energy measurement on heterogeneous android systems. In
ReCoSoc, pages 1–8. ACM, 2018.
[34] Igor Costa, Péricles Alves, Henrique Nazaré, and Fernando Magno Quint ao Pereira. Just-
in-time value specialization. In CGO, pages 33:1–33:11. ACM, 2013.
[35] Bruno Coutinho, Diogo Sampaio, Fernando Magno Quint ao Pereira, and Wagner Meira Jr.
Divergence analysis and optimizations. In PACT, pages 320–329. IEEE, 2011.
[36] Bruno Coutinho, Diogo Sampaio, Fernando Magno Quint ao Pereira, and Wagner Meira
Jr. Profiling divergences in gpu applications. Concurrency and Computation: Practice and
Experience, 25(6):775–789, 2013.
[37] Bruno Rocha Coutinho, Diogo Nunes Sampaio, Fernando Magno Quint ao Pereira, and Wag-
ner Meira Jr. Performance debugging of gpgpu applications with the divergence map. In
SBAC-PAD, pages 33–40. IEEE, 2010.
[38] Ron Cytron, Jeanne Ferrante, Barry K. Rosen, Mark N. Wegman, and F. Kenneth Zadeck.
An efficient method of computing static single assignment form. In POPL, pages 25–35.
ACM, 1989.
40
[39] Leonardo L P da Mata, Fernando Magno Quint ao Pereira, and Renato Ferreira. Automatic
parallelization of canonical loops. Science of Computer Programming, 78(8):1193–1206, 2013.
[40] Leonardo Padovani da Mata, Fernando Magno Quint ao Pereira, and Renato Antônio Ferreira.
Automatic parallelization of canonical loops. In SBLP, pages 1–15. SBC, 2009.
[41] Igor Rafael de Assis Costa, Henrique Nazaré Santos, Péricles Rafael Alves, and Fernando
Magno Quint ao Pereira. Just-in-time value specialization. Computer Languages and Systems
and Structures, 40(2):37–52, 2014.
[42] Marco Túlio de Oliveira Valente, Fernando Magno Quint ao Pereira, Roberto da Silva Bigo-
nha, and Mariza Andrade da Silva Bigonha. A coordination model for ad hoc mobile systems.
In EURO-PAR, pages 1075–1081. Springer, 2003.
[43] Marco Túlio de Oliveira Valente, Roberto da Silva Bigonha, Mariza Andrade da Silva Bigo-
nha, and Fernando Magno Quint ao Pereira. A coordination model for ad hoc mobile systems
and its formal semantics. In WCSF, pages 58–67. SBC, 2002.
[44] Ning Ding, Daniel Wagner, Xiaomeng Chen, Abhinav Pathak, Y. Charlie Hu, and Andrew
Rice. Characterizing and modeling the impact of wireless signal strength on smartphone
battery drain. In SIGMETRICS, pages 29–40, New York, NY, USA, 2013. ACM.
[45] Douglas do Couto, Kezia Andrade, Gleison Souza, and Fernando Pereira. Etino: Colocação
automática de computação em hardware heterogêneo. In SBLP, pages 1–14. SBC, 2015.
[46] Douglas Teixeira do Couto and Fernando Magno Quint ao Pereira. The design and imple-
mentation of a non-iterative range analysis algorithm on a production compiler. In SBLP,
pages 1–15. SBC, 2011.
[47] Douglas do Couto Teixeira, Sylvain Collange, and Fernando Magno Quint ao Pereira. Fusion
of calling sites. In SBAC-PAD, pages 90–97. IEEE, 2015.
[48] Rubens Emilio, Mateus Tymburiba, and Fernando Pereira. Inferênica estática da frequência
máxima de instruções de retorno para detecção de ataques rop. In SBSeg, pages 2–15. SBC,
2015.
[49] Saggioro Felipe, Paisante Vitor, Rodrigues Raphel, Barbosa Leonardo, and Fernando Pereira.
Crosschecking distributed data to detect integer overflow. Revista IEEE America Latina,
13(4):1083–1089, 2015.
[50] Augusto Fernando, Menezes Gustavo, Marcondes Pablo, Fernando Pereira, Chi Hao, Marcos
Jose, , and Barbosa Leonardo. Defending internet of things against exploits. Revista IEEE
America Latina, 13(4):1112–1119, 2015.
[51] Bruno Morais Ferreira, Fernando Magno Quint ao Pereira, Hermann Rodrigues, and Bri-
taldo Silveira Soares-Filho. Optimizing a geomodeling domain specific langauge. In SBLP,
pages 87–101. Springer, 2012.
[52] Denzil Ferreira, Anind K. Dey, and Vassilis Kostakos. Understanding human-smartphone
concerns: A study of battery life. In Pervasive, pages 19–33, Berlin, Heidelberg, 2011.
Springer-Verlag.
41
[53] Mateus Tymburibá Ferreira, Rubens Emı́lio Alves Moreira, and Fernando Magno Quint ao
Pereira. Inference of peak density of indirect branches to detect rop attacks. In CGO, pages
150–159. ACM, 2016.
[54] Peter Greenhalgh. Big. little processing with arm cortex-a15 & cortex-a7. ARM White paper,
pages 1–8, 2011.
[55] Dominik Grewe and Michael FP O’Boyle. A static task partitioning approach for heteroge-
neous systems using opencl. In Compiler Construction, pages 286–305. Springer, 2011.
[56] Mary Hall, David Padua, and Keshav Pingali. Compiler research: The next 50 years. Com-
mun. ACM, 52(2):60–67, 2009.
[57] Julien Jaeger, Patrick Carribault, and Marc Pérache. Fine-grain data management directory
for openmp 4.0 and openacc. Concurrency and Computation: Practice and Experience, pages
1528–1539, 2015.
[58] Izabela Kareninna, Fernando Pereira, and Leonardo Barbosa. Detecção automática de vul-
nerabilidades em código protegido por canários. In SBSeg, pages 1–14. SBC, 2013.
[59] Jonathan K Lee, Jens Palsberg, and Fernando Magno Quint ao Pereira. Alias register allo-
cation for straight-line programs is np-complete. In ICALP, pages 680–691. Springer, 2007.
[60] Michael L. Littman, Anthony R. Cassandra, and Leslie Pack Kaelbling. Readings in agents.
In Michael N. Huhns and Munindar P. Singh, editors, International Conference on Machine
Learning (ICML), chapter Learning Policies for Partially Observable Environments: Scaling
Up, pages 495–503. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1998.
[61] Yepang Liu, Chang Xu, and S. C. Cheung. Where has my battery gone? finding sensor
related energy black holes in smartphone applications. In PerCom, pages 2–10, Washington,
DC, USA, 2013. IEEE.
[62] Maroua Maleej, Vitor Paisante, Pedro Ramos, Laure Gonnord, and Fernando Magno Quint
ao Pereira. Pointer disambiguation via strict inequalities. In CGO, pages 134–147. ACM,
2017.
[63] Christos Margiolas and Michael F. P. O’Boyle. Portable and transparent software managed
scheduling on accelerators for fair resource sharing. In CGO, pages 82–93. ACM, 2016.
[64] Cor Meenderinck and Ben H. H. Juurlink. Nexus: Hardware support for task-based program-
ming. In DSD, pages 442–445. Springer, 2011.
[65] Leandro T. C. Melo, Rodrigo G. Ribeiro, Marcus R. de Araújo, and Fernando Magno Quintão
Pereira. Inference of static semantics for incomplete c programs. Proc. ACM Program. Lang.,
2(POPL):29:1–29:28, December 2017.
[66] Gleison Mendonça, Breno Guimarães, Péricles Alves, Márcio Pereira, Guido Araújo, and
Fernando Magno Quintão Pereira. Dawncc: Automatic annotation for data parallelism and
offloading. TACO, 14(2):13:1–13:25, 2017.
42
[67] Gleison Souza Diniz Mendonça, Breno Campos Ferreira Guimar aes, Péricles Rafael Oliveira
Alves, Márcio Machado Pereira, Guido Araújo, and Fernando Magno Quint ao Pereira. Au-
tomatic insertion of copy annotation in data-parallel programs. In SBAC, pages 34–41. IEEE,
2016.
[68] Teo Milanez, Sylvain Collange, Fernando Magno Quint ao Pereira, Wagner Meira Jr, and
Renato Ferreira. Thread scheduling and memory coalescing for dynamic vectorization of
spmd workloads. Parallel Computing, 40(9):548–558, 2014.
[69] Teo Milanez, Sylvain Collange, Fernando Magno Quintao Pereira, Wagner Meira Jr., and
Renato A. Ferreira. Data and instruction uniformity in minimal multi-threading. In SBAC-
PAD, pages 270–277. IEEE, 2012.
[70] Kézia Correa Andrade Moreira, Gleison Souza Diniz Mendonça, Breno Campos Ferreira Gui-
mar aes, and Fernando Magno Quint ao Pereira. Paralelização automatica de codigo com
diretivas openacc. In SBLP, pages 1–14. SBC, 2016.
[71] Rubens E A Moreira, Sylvain Collange, and Fernando Magno Quint ao Pereira. Function call
re-vectorization. In PPoPP, pages 313–326. ACM, 2017.
[72] Rubens Emilio Alves Moreira, Sylvain Collange, and Fernando Magno Quint ao Pereira.
Definição semântica de blocos everywhere para programação simd. In SBLP, pages 29–42.
SBC, 2016.
[73] Rubens Emı́lio Alves Moreira, Mateus Tymburibá, and Fernando Pereira. Riprop: A dynamic
detector of rop attacks. In CBSoft Tools, pages 9–16. SBC, 2015.
[74] Venkata K Nandivada, Fernando Magno Quint ao Pereira, and Jens Palsberg. A framework
for end-to-end verification and evaluation of register allocators. In SAS, pages 153–169.
Springer, 2007.
[75] Henrique Nazaré, Izabela Maffra, Willer Santos, Leonardo Barbosa, Laure Gonnord, and
Fernando Magno Quint ao Pereira. Validation of memory accesses through symbolic analyses.
In OOPSLA, pages 791–809. ACM, 2014.
[76] John Nickolls and William J Dally. The GPU computing era. Micro, IEEE, 30(2):56–69,
2010.
[77] Rajiv Nishtala, Paul M. Carpenter, Vinicius Petrucci, and Xavier Martorell. Hipster: Hybrid
task manager for latency-critical cloud workloads. In HPCA, pages 409–420. IEEE, 2017.
[78] Cedric Nugteren and Henk Corporaal. Bones: An automatic skeleton-based C-to-CUDA
compiler for GPUs. TACO, 11(4):35:1–35:25, 2014.
[79] Vitor Paisante, Zafra Felipe, Rodrigues E, Leonardo Oliveira, and Fernando Pereira. Pre-
venção de ataques em sistemas distribuı́dos via análise de intervalos. In SBSeg, pages 1–14.
SBC, 2013.
[80] Vitor Paisante, Maaroua Maleej, Laure Gonnord, Leonardo Barbosa, and Fernando
Magno Quint ao Pereira. Symbolic range analysis of pointers. In CGO, pages 171–181.
ACM, 2016.
43
[81] Vinicius Petrucci, Michael A Laurenzano, John Doherty, Yunqi Zhang, Daniel Mosse, Jason
Mars, and Lingjia Tang. Octopus-man: QoS-driven task management for heterogeneous
multicores in warehouse-scale computers. In HPCA, pages 246–258. IEEE, 2015.
[82] Guilherme Piccoli, Henrique Nazaré Santos, Raphael Ernani Rodrigues, Christiane Pousa,
Edson Borin, and Fernando Magno Quint ao Pereira. Compiler support for selective page
migration in numa architectures. In PACT, pages 369–380. IEEE, 2014.
[83] Gabriel Poesia, Breno Guimaraes, Fabricio Ferracioli, and Fernando Magno Quint ao Pereira.
Static placement of computation on heterogeneous devices. In OOPSLA, pages 1–18. ACM,
2017.
[84] Gabriel Silva Quadros and Fernando Magno Quint ao Pereira. Static detection of address
leaks. In SBSeg, pages 1–14. SBC, 2011.
[85] Francisco Barat Quesada. Digital signal processor, December 10 2015. US Patent App.
14/964,817.
[86] Pedro Henrique Ramos, Gleison Souza Diniz Mendonça, Guilherme Mendes Leobas, , , Divino
Cesar, Guido Araújo, and Fernando Magno Quint ao Pereira. Automatic identification and
annotation of tasks in structured programs. In PACT, page To Appear. IEEE, 2018.
[87] Rodrigo Geraldo Ribeiro, Leandro Terra Cunha Melo, Marcus Rodrigues de Araújo, and
Fernando Magno Quint ao Pereira. Compilação parcial de programas escritos em c. In SBLP,
pages 15–28. SBC, 2016.
[88] Andrei Rimsa, Marcelo d’Amorim, and Fernando Magno Quint ao Pereira. Efficient static
checker for tainted variable attacks. In SBLP, pages 16–30. SBC, 2010.
[89] Andrei Rimsa, Marcelo d’Amorim, and Fernando Magno Quint ao Pereira. Tainted flow
analysis on e-ssa-form programs. In CC, pages 122–141. Springer, 2011.
[90] Andrei Rimsa, Marcelo D’Amorim, Fernando Magno Quint ao Pereira, and Roberto Bigo-
nha. Efficient static checker for tainted variable attacks. Science of Computer Programming,
80(A):91–105, 2014.
[91] Rodrigo Caetano O Rocha, Luı́s Fabrı́cio Wanderley Góes, and Fernando Magno Quint ao
Pereira. An algebraic framework for parallelizing recurrence in functional programming. In
SBLP, pages 140–155. SBC, 2016.
[92] Bruno Rodrigues, Diego Aranha, and Fernando Magno Quint ao Pereira. Sparse represen-
tation of implicit flows with applications to side-channel detection. In CC, pages 110–120.
ACM, 2016.
[93] Raphael Rodrigues and Fernando Pereira. Prevenção automática de ataques de não-
terminação. In SBLP, pages 21–40. SBC, 2013.
[94] Raphael Ernani Rodrigues, Victor Hugo Sperle Campos, and Fernando Magno Quint ao
Pereira. A fast and low-overhead technique to secure programs again integer overflows. In
CGO, pages 29:1–29:11. ACM, 2013.
44
[95] Leili Salimian and Faramarz Safi. Survey of energy efficient data centers in cloud computing.
In UCC, pages 369–374, Washington, DC, USA, 2013. IEEE Computer Society.
[96] Diogo Sampaio, Rafael M Sousa, Sylvain Collange, and Fernando Magno Quint ao Pereira.
Divergence analysis. TOPLAS, 35(4):1–37, 2013.
[97] Diogo Nunes Sampaio, Elie Gedeon, Fernando Magno Quint ao Pereira, and Sylvain Collange.
Spill code placement for simd machines. In SBLP, pages 12–26. Springer, 2012.
[98] Henrique Santos, Fernando Pereira, and Leonardo Barbosa. Verificação estática de acessos a
arranjos em c. In SBSeg, pages 29–42. SBC, 2013.
[99] Bruno Silva, Diego Aranha, and Fernando Pereira. Uma técnica de análise estática para
detecção de canais laterais baseados em tempo. In SBSeg, pages 16–29. SBC, 2015.
[100] Bruno Silva, Fernando Pereira, and Leonardo Barbosa. Uma representação intermediária
para a detecção de vazamentos implı́citos de informação. In SBSeg, pages 15–28. SBC, 2013.
[101] Bruno Silva, Fernando Pereira, Leonardo Barbosa, and Antônio Loureiro. Flow tracker: Uma
ferramenta para detecção de vazamento de informações sigilosas. In CBSoft Tools, pages 8–15.
SBC, 2013.
[102] Bruno Silva, Leonardo Ribeiro, and Fernando Pereira. Flowtracker - detecção de código não
isócrono via análise estática de fluxo. In CBSoft Tools, pages 97–104. SBC, 2015.
[103] Marcos Yukio Siraichi, Vinı́cius Fernandes dos Santos, Sylvain Collange, and Fernando
Magno Quintao Pereira. Qubit allocation. In CGO, pages 113–125, New York, NY, USA,
2018. ACM.
[104] Rodrigo Sol, Fernando Magno Quint ao Pereira, and Mariza A S Bigonha. Removing overflow
tests via run-time partial evaluation. In SBLP, pages 1–15. SBC, 2010.
[105] Rodrigo Sol, Christophe Guillon, Fernando Magno Quint ao Pereira, and Mariza Bigonha.
Dynamic elimination of overflow tests in a trace compiler. In CC, pages 2–21. Springer, 2011.
[106] Richard S. Sutton and Andrew G. Barto. Introduction to Reinforcement Learning. MIT
Press, Cambridge, MA, USA, 1st edition, 1998.
[107] Andre Tavares, Quentin Colombet, Mariza Bigonha, Christophe Guillon, Fernando
Magno Quint ao Pereira, and Fabrice Rastello. Decoupled graph-coloring register alloca-
tion with hierarchical aliasing. In SCOPES, pages 1–10. ACM, 2011.
[108] André Luiz C Tavares, Fernando Magno Quint ao Pereira, Mariza Bigonha, and Roberto
Bigonha. Efficient ssi conversion. In SBLP, pages 31–45. SBC, 2010.
[109] André Luiz Camargos Tavares, Benoit Boissinot, Fernando Magno Quint ao Pereira, and
Fabrice Rastello. Parameterized construction of program representations for sparse dataflow
analyses. In CC, pages 18–39. Springer, 2014.
[110] Fernando Teixeira, Fernando Pereira, Gustavo Vieira, Pablo Marcondes, Hao Wong, José
Nogueira, and Leonardo Oliveira. Siot: Defendendo a internet das coisas contra exploits. In
SBRC, pages 1–15. SBC, 2014.
45
[111] Fernando A. Teixeira, Fernando M.Q. Pereira, Hao-Chi Wong, Jose M.S. Nogueira, and
Leonardo B. Oliveira. SIoT: Securing internet of things through distributed systems analysis.
Future Generation Computer Systems, 2017.
[112] Raja Vallée-Rai, Phong Co, Etienne Gagnon, Laurie Hendren, Patrick Lam, and Vijay Sun-
daresan. Soot - a java bytecode optimization framework. In CASCON, pages 13–. IBM Press,
1999.
[113] Sven Verdoolaege, Juan Carlos Juega, Albert Cohen, José Ignacio Gómez, Christian Tenllado,
and Francky Catthoor. Polyhedral parallel code generation for cuda. TACO, 9(4):54:1–54:23,
2013.
[114] Campos Victor, Alves Péricles, , and Pereira Fernando. Restritificação. In SBLP, pages 1–14.
SBC, 2015.
[115] N. Vijaykrishnan, M. Kandemir, M. J. Irwin, H. S. Kim, and W. Ye. Energy-driven integra-

ted hardware-software optimizations using simplepower. SIGARCH Comput. Archit. News,
28(2):95–106, 2000.
[116] Matheus Vilela and Fernando Pereira. Otimizações de código sensı́veis ao contexto de cha-
mada. In WTDSoft, pages 1–6. SBC, 2013.
[117] Christopher J. C. H. Watkins and Peter Dayan. Q-learning. Machine Learning, 8(3):279–292,
May 1992.
[118] Jingyu Yan. Intelligent Battery Management System for Electric Vehicles. PhD thesis, The
Chinese University of Hong Kong (People’s Republic of China), 2010. AAI3484737.
[119] Mohamed Zahran. Heterogeneous computing: Here to stay. Queue, 14(6):40:31–40:42, 2016.
46

Grant PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Grant PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Departamento de Ciência da Computação

Universidade Federal de Minas Gerais

Geração Eficiente de Código de Qualidade

Proposta submetida ao CNPq para solicitação

Candidato à bolsa: Fernando Magno Quintão Pereira

Interrupção da Bolsa em 2018

Capacidade do proponente: o candidato formou-se doutor em 2008 pela University of Cali-

Descrição: O hardware contemporâneo encontrado em telefones celulares implementa várias ma-

Recursos solicitados: solicita-se a renovação da Bolsa de Produtividade em Pesquisa Nı́vel 2

1.1 Objetivos do Projeto

1.2 Relevância e Impacto do Projeto

Definition 2.1 (Configuração de hardware) Uma arquitetura heterogênea é formada por um

2.1 O Universo de Configurações de Hardware

1L4B 4L1B 4L1B 4L4B

Cada ponto na figura representa a média de 10 execuções na mesma configuração, usando a

2.2 Fases de Programas

2.3 Em Busca da Configuração Ideal de Hardware

Definition 3.1 Escalonamento de Programas em Arquiteturas Heterogêneas ( SPha)

3.1 Objetivo 1: Extração de Caracterı́sticas

Figura 5: O protótipo a ser produzido no primeiro ano deste projeto.

3.2 Objetivo 2: Adaptação do Programa

3.3 Objetivo 3: Geração final do código

3.4 O Projeto Extendido – Anos 2 e 3

Passo 1 – Medição de Energia em Sistemas Distribuı́dos: Vamos desenvolver uma infra-

Passo 3 – Descarga Automática de Código: Vamos implementar um compilador que possa

Ano Ano 1 Ano 2 Ano 3

Figura 8: Cronograma esperado para o projeto.

3.6 Infra-Estrutura Existente

• [Perı́odicos]: pelo menos seis artigos em periódicos A1 ou A2.

• [Conferências internacionais]: pelo menos seis artigos em conferências internacionais Qua-

• [Conferências nacionais]: pelo menos nove artigos em conferências nacionais.

• [Graduação]: quatro alunos de iniciação cientı́fica.

• [Mestrado]: cinco alunos de mestrado.

• [Doutorado]: dois alunos de doutorado.

5 Compilação de Atividades de Pesquisa Desenvolvidas

5. Existem somente quatro conferências na área de linguagens de programação classificadas como

6. Não existem periódicos na área de linguagens de programação classificados como A1. O

5.2 Pesquisa Comentada

Mestrado. Durante seu mestrado, Fernando investigou ambientes de programação distribuı́dos.

Doutorado. Durante o doutorado que Fernando lançou-se em definitivo à pesquisa em compilado-

Google. Em 2008 Fernando realizou um estágio de pesquisa na empresa Google, em um escritório

5.2.2 Perı́odo 2009-2017

Segurança computacional A segurança do computador tem sido sempre um problema impor-

Compilação Just-in-Time Nos próximos anos, linguagens de programação dinâmicas, como

• Otimizações de código sensı́veis a contexto de chamada de funções [116, 23].

• Verificações de acesso a memória em programas escritos em linguagens fracamente tipadas [98,

• Análise de Ponteiros [62, 80, 7, 3, 29, 82, 6].

• Mensuração de energia [24].

• Compilação para arquiteturas heterogêneas [47].

• Compilação de linguagens funcionais [91, 51, 71].

• Return Oriented Programming [73, 48, 53].

• Representações intermediárias de código [109, 107, 108].

• Análise de intervalos de variáveis inteiras [30, 46, 82, 94, 5].

• Análise de fluxo de informação [93, 100, 101, 99, 102, 92].

• Análise de sistemas distribuı́dos [49, 50, 110, 79].

5.2.3 2018 – Pós-Doutorado

5.3 Resumo Quantitativo da Produção Intelectual

Qualidade. A Figura 12 classifica a produção bibliográfica de Fernando Pereira de acordo com o

Projeto Agência: Edital Perı́odo Valor

Empresa: Projeto Perı́odo Valor

6.2 Participação em Grupos de Pesquisa

• Tı́tulo: Automatização de Testes de Software em Sistemas Embarcados

• Tı́tulo: Paralelização Automática de Código para Aparelhos Móveis