VC2015 и VC2010. Файл вырастает в 3,5раза Опции

[megajohn]

Добрый день
вот такой вопрос, есть проект для VC2010, на выходе файл 182k
тот же самый проект, скомпиленный в VC2015 дает файл 614k

посему немного вопросов для тех, кто разбирается в тонкостях линковки:
- каким софтом можно узнать, что же так разрослось ?
- так как конечный результат хочу выложить в свободный доступ для желающих, то какой вариант выкладывать ?

вот эти файлики, если вдруг кому-то проще посмотреть
 prj_VC2010_vs_VC2015.ZIP ( 347.36 килобайт ) Кол-во скачиваний: 13

[DASM]

определения типов , входящих в эти строки можно? что то додумывать не хочется

[jcxz]

определения типов , входящих в эти строки можно? что то додумывать не хочется

Код

struct OscRaw {
  uint chainN;                //кол-во не-NULL указателей chain
  uint nv0, ixf0, nvf0;       //соответственно chain[0].nv, chain[0].ixf и chain[0].fmt[ixf].n на момент защёлкивания Get()
  FILETIME timestamp;         //временная метка последних принятых данных
  char timestampOk;           //!=0 - timestamp валидно
  uint oscsrcNV[OSCSRC_n];    //кол-во векторов по каждому источнику осц. непрерывным участком от самого нового вектора до ближайшего разрыва по данному источнику
  HCOsc *chain[OSC_BRING_N];  //массив блоков данных векторов осц. (каждый имеет заголовок HCOsc)
  TIPCALL OscRaw() { ZeroMemory(this, sizeof(*this)); }
  TIPCALL OscRaw(OscRaw const &src) { ZeroMemory(this, sizeof(*this)); *this = src; }
  TIPCALL ~OscRaw() { Destroy(); }
  void TIPCALL Get();
  void TIPCALL Destroy();
  OscRaw & operator =(OscRaw const &);
};
struct HCOsc {
  long volatile use; //кол-во пользователей данного элемента (кол-во link-ов на него)
  uint volatile nv;  //кол-во векторов в данном элементе
  uint ixf;          //индекс последнего записанного элемента fmt (кол-во_записанных_элементов_fmt - 1)
  struct Format {
    u64 map;         //бит-карта источников осц. для n векторов
    uint n;          //кол-во векторов осц. которые соответствуют карте map
    uint TIPCALL GetVktOffs(uint) const;
  } fmt[64];         //список описателей формата векторов в данном элементе HCOsc
  void TIPCALL Delete() { if (!InterlockedDecrement(&use)) delete this; }
};

А приведённый кусок кода - это участок результата компиляции OscRaw::Get():

Код

void TIPCALL OscRaw::Get()
{
  HCOsc *p, **pb = &chain[0];
...
  if (chainN = n) {
    nv0 = (p = chain[0])->nv;
    nvf0 = p->fmt[ixf0 = p->ixf].n;
  }
  timestamp = ::timestamp;
  timestampOk = ::timestampOk;
  memcpy(oscsrcNV, (void *)&::oscsrcNV[0], sizeof(oscsrcNV));
  LeaveCriticalSection(&csb);
}

Как видите - volatile в данных местах нету.

PS: Копирование в промежуточную переменную p = chain[0] это уже я позже добавил. В таком варианте эти лишние чтения указателя уже пропадают.
Т.е. - компилятор почему-то сам не догадывается так сделать (сохранить chain[0] в регистре), но если ему явно указать на это, поместив указатель в отдельную переменную (p), то p он уже оптимизирует в регистр.
По идее - раз массив chain указан без volatile, то значит не имеет side effects, а значит его члены можно перемещать куда угодно и создавать сколько угодно копий.

[XVR]

PS: Копирование в промежуточную переменную p = chain[0] это уже я позже добавил. В таком варианте эти лишние чтения указателя уже пропадают.
Т.е. - компилятор почему-то сам не догадывается так сделать (сохранить chain[0] в регистре)

Он не может. У вас там присваивания в поля структуры OscRaw (nv0 и nvf0). Для компилятора это запись в память. Видимо анализ указателей у VC хромает (или выключен), и он считает, что эта запись потенциально может попасть в любой глобальный объект (ч том числе и в те, к которым обращаются через указатель). Поэтому содержимое chain может измениться (с точки зрения компилятора).

но если ему явно указать на это, поместив указатель в отдельную переменную (p), то p он уже оптимизирует в регистр.

тут вы взяли отвественность на себя, явно переместив значение в локальную переменную. Для неё pointer анализ говорит, что она ни с какими указателями не пересекается.

По идее - раз массив chain указан без volatile, то значит не имеет side effects, а значит его члены можно перемещать куда угодно и создавать сколько угодно копий.

Нет. В массив могут записать 'сбоку' (не через указатель на него).